[Top][All Lists]

[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
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]