Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16170
| 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> |
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
Re: looking for consistent C-c trap behavior gentoo_eshoes@tutanota.com - 2020-04-19 00:45 +0200
csiph-web