[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: [Help-bash] How to trap SIGTERM?
Date: Mon, 22 Apr 2013 09:49:06 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

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


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]