On 1/8/14, 12:01 PM, Paweł Gołaszewski wrote: > Hello, > > I think I've found bug in signal handling in bash. > > Look at 2 scripts: > http://www.blues.gda.pl/SOURCES/show_logs.sh > http://www.blues.gda.pl/SOURCES/show_logs.zsh > > Both are identical. "zsh" version works fine, "bash" version doesn't. > After start everything is fine, a can send _one_ HUP signal and it works > as expected. The next HUP simply doesn't work. Even more: INT signal > (Ctrl+C) works... like SIGHUP.
There are a few things going on here. First, after the first SIGHUP, you are running the entire script from a trap handler. Bash treats things in a trap handler context a little specially. Second, bash doesn't allow recursive trap invocations: it blocks the signal for which the trap is being run while the trap command is being executed, as if you were running a signal handler. That's why the second SIGHUP has no apparent effect. Also, bash doesn't set the flag that a signal is no longer pending until after it executes the trap command. This means that the flag is still set for SIGHUP (signal 1) (because you're running from the trap handler) when the SIGINT (signal 2) arrives and is processed. Bash processes signals in order, and so attempts to execute the trap commands for SIGHUP before SIGINT. That's why SIGINT appears to act like SIGHUP. (This is arguably a bug.) I have made several changes to the trap command processing, and things in bash-4.3 should be closer to the way you want them to run. However, there is enough variation in how different shells handle this situation (bash, ksh93, dash, and zsh all act differently) that there's no consensus on exactly what's "right". Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/