Re: looking for consistent C-c trap behavior

[gentoo_eshoes--- via Bug reports for the GNU Bourne Again SHell]

Apr 18, 2020, 22:03 by chet.ra...@case.edu:

> On 4/17/20 3:59 PM, gentoo_eshoes--- via Bug reports for the GNU Bourne
> Again SHell wrote:
>
>> I've noticed that if I trap SIGINT in a bash script, the behavior when 
>> encountering C-c depends on whether an external command (eg. 'sleep 100') or 
>> a builtin command (like 'read -p') was encountered.
>>
>
> It's only `read', and it happens when bash is executing in default mode.
>
That's pretty cool that's only 'read', I wrongly assumed(without any prior 
testing) that that applies to any builtin. I still haven't tested, I trust you.

> Here's what I wrote (off-list) earlier this month about it; it has come
> up several times before:
>
> =====
> The idea is that trapping the signal doesn't interrupt the read, kind of
> like a read system call getting restarted if interrupted by a signal and
> reading from the terminal. Since the read doesn't get interrupted, you have
> to satisfy it by entering newline. If you didn't have the trap on INT it
> would interrupt the read.
>
> Bash has behaved this way in its default mode for just about forever. In
> posix mode, it interrupts the read system call.
>
can confirm that indeed `bash --posix` does interrupt the 'read -p' on first 
C-c, however, the inside-trap seen exit code is 0, but if the trap doesn't 
`exit` itself, then the exit code after the 'read -p' is seen correctly as 130, 
ie.
$ ./sigintread.bash 
Press C-c here...^Cinterrupted sees exit code '0'

Normal exit sees ec=130

Would it be possible to somehow get 130 even inside the trap function?

this would then be equivalent with interrupting 'sleep' for example:
$ ./sigintread.bash 
^Cinterrupted sees exit code '130'

Normal exit sees ec=130


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...