bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: signals ignored in a subshell


From: Chet Ramey
Subject: Re: signals ignored in a subshell
Date: Sun, 5 Apr 2020 16:21:53 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

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    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]