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