Re: signals ignored in a subshell

[Chet Ramey]

On 4/5/20 5:42 AM, Oğuz wrote:

>> But I see what you mean now, during the read that's called from the
>> trap execution call of foo, SIGINT is blocked - that most probably should
>> not happen, and it looks as if when the trap handler exits, the
>> original read is resumed, that certainly shouldn't happen.
>>
>>
> Exactly. In my opinion, read should behave the way wait does: fail upon a
> signal for which a trap is set, and return a non-zero value when handler
> returns. Don't really know how hard it would be to implement that though.

That's not how read is defined to behave. wait has special wording defining
what happens when it receives a signal. Bash default mode behaves as I
described previously -- trapping the signal and returning from the handler
results in the read being restarted -- and posix mode will run the trap
handler before returning from the `read' builtin.

In bash-5.0, posix mode would return from the trap handler on the second
SIGINT; that was a consequence of not allowing recursive signal handlers
(which caused other problems, see
https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00014.html).
The devel branch requires that the read be satisfied once, since
interrupting it will now run the trap handler recursively.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/