Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16170

Re: looking for consistent C-c trap behavior

From gentoo_eshoes@tutanota.com
Newsgroups gnu.bash.bug
Subject Re: looking for consistent C-c trap behavior
Date 2020-04-19 00:45 +0200
Message-ID <mailman.634.1587249913.3066.bug-bash@gnu.org> (permalink)
References <M58iOBd--3-2@tutanota.com> <a8b7d5fc-0a64-0a0e-bd49-7f808f937813@case.edu> <M5EEHGq--3-2@tutanota.com> <M5ESsGC--3-2@tutanota.com>

Show all headers | View raw




Apr 18, 2020, 23:41 by gentoo_eshoes@tutanota.com:

>
> On another note, I naively tried to patch out the POSIX requirement, for my own/local_use puposes but had no effect:
> in this code
> +  /* posix mode SIGINT during read -e. We only get here if SIGINT is trapped. */
> +  if (posixly_correct && this_shell_builtin == read_builtin && sig == 2)
> +    {
> +      last_command_exit_value = 128|SIGINT;
> +      throw_to_top_level ();
> +    }
> by removing "posixly_correct &&" from above. I've no idea why that would have no effect, a bit stumped.
> I've even tried with a prior 'make clean'. The only explanation is that some other code that happens only during `POSIXly correct` mode is affecting this somehow...
>
regarding the above, I stand corrected: it does indeed have effect but only on 'read -e' (just as the comment states), that bash_event_hook() function isn't entered for 'read -p' which to me was surprising, yet no doubt correct(I'm guessing).
The code that allows 'read -p' to be interrupted when posixly_correct, must then be somewhere else, I shall keep lookin', yet I fear I might not find it :-"

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: looking for consistent C-c trap behavior gentoo_eshoes@tutanota.com - 2020-04-19 00:45 +0200

csiph-web