On 02/18/2013 02:39 AM, Chet Ramey wrote: > On 2/17/13 7:46 PM, Pádraig Brady wrote: > >>>> I notice the following will wait for 5 seconds for >>>> the timeout process to end with SIGALRM, rather than >>>> immediately due to kill sending the SIGTERM. >>> >>> I think the way to approach this is to change the SIGTERM handling from >>> straight SIG_IGN to a handler installed with SA_RESTART that catches the >>> signal but does nothing with it. >>> >>> That will allow the shell to note whether it receives a SIGTERM between >>> fork and exec and react accordingly. >> >> Thanks for continuing to look at this. >> Just in case you need to consider other options, >> elaborating a bit on my previous suggestion: > > I looked at this, and it ended up being a little more complicated and a > little less flexible than the approach I adopted. > >> Your suggested method I think is to have a handler something like >> the following which should work too, but perhaps with the caveat >> that the exit status of the child before the exec might not have >> the signal bit set. > > No, much simpler. The signal handler just sets a flag. It's only > installed by interactive shells, so the flag never changes in any other > shell. Setting the flag to 0 at appropriate times and checking for > non-zero values at appropriate times is all that's needed. If a child > process finds the flag non-zero, it calls the usual terminating signal > handler, which ends up killing the shell with the same signal.
I've confirmed that bash 4.3 alpha doesn't have the issue. Well I can't reproduce easily at least. I didn't notice a NEWS item corresponding to it though. If I wanted to inspect this code change what would be the best approach? thanks, Pádraig.
