On Sat, 11 Jan 2014, Chet Ramey wrote: > 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.
ok, but let's document it. Anyway - some "trap reset" would be very good thing. > 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.) Yes, it is. And it's _very_ confusing... :) > 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. Can you give some patch/link? > 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". First of all it has to behave "logical". Standarisation is the next step. Anyway - no matter what it "the right way" few words about "the bash way" in manual would be very good thing :) -- pozdr. Paweł Gołaszewski jid:blues<at>jabber<dot>gda<dot>pl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.