Re: bash signal trap bug

[Paweł Gołaszewski]

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.