Re: [Help-bash] How to trap SIGTERM?

[Chet Ramey]

On 4/22/13 2:13 AM, Pierre Gaston wrote:

>     > The shell is doing some strange handling, if I change the script to:
>     >
>     > #!/usr/bin/env bash
>     > trap "echo booh!" EXIT
>     > sleep 5  & wait $!
>     >
>     > I get:
>     >
>     > $ for i in 2  15;do ./sigtest $i;done
>     > booh!
>     > Child exit normally: 129
>     > booh!
>     > Child exited with status: 15 and signal: 15
>     >
>     > As I said I'm not sure what are the rationale behind all that.
> 
>     It can be found in the article.  Sending SIGINT from a program to just the
>     shell is somewhat artificial, since a keyboard-generated SIGINT goes to 
> the
>     process group.  When the shell is not interactive, as it is in this case,
>     the shell assumes that the SIGINT was sent from the keyboard and received
>     by the foreground process group.  It uses the child's exit status as a
>     guide for signal disposition: if the child exits due to SIGINT, the shell
>     acts as if it received the SIGINT; if not, the shell effectively ignores
>     the signal.
> 
> 
> I see thanks, so if I press C-c instead sleep would (or at least should)
> indictates it
> has exited due to sigint and as a result the script would do so also and
> all is ok.

More or less.  A keyboard-generated SIGINT gets sent to the terminal's
process group.  When job control is not active, the shell and all of its
child processes are in the same process group as the terminal, and will
receive keyboard-generated SIGINTs.  (This, incidentally, is why background
commands ignore SIGINT by default when job control is not active.)

If you had sent SIGINT from the keyboard, sleep would have gotten it and
exited.  The shell would have noticed that it exited due to SIGINT and
reacted accordingly.

>     The shell also assumes that if there is a trap set on SIGINT, that the
>     programmer must want to know about keyboard-generated signals whether or
>     not the foreground process responds to them, and runs the trap handler.
>     This is a heuristic that's worked out pretty well so far.
> 
>     Running the sleep in the background and the wait in the foreground is also
>     documented in the section you originally quoted from the manual page.
> 
> 
> I see, somehow I was expecting 128+2 instead of 129

Maybe, but the sleep did not exit due to SIGINT.  It exited normally since
it never received the signal.  The standard says only that the exit status
must be greater than 128, so the shell synthesized wait's exit status from
that.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/