Re: Cannot trap INT in child of an interactive shell

[Chet Ramey]

On 8/13/14, 12:08 PM, Greg Wooledge wrote:
> Bash 4.3.22, HP-UX.
> 
> imadev:~$ child() { trap - INT; trap 'echo I got an INT; trap - INT; kill 
> -INT $
> BASHPID' INT; while true; do sleep 1; done; }; child &
> [1] 19116
> imadev:~$ kill -INT 19116
> imadev:~$ kill -INT 19116
> imadev:~$ kill -TERM 19116
> [1]+  Terminated              child
> 
> The manual says:
> 
>       Non-builtin commands run by bash have signal handlers set to the
>       values inherited by the shell from its parent.  When job control is
>       not in effect, asynchronous commands ignore SIGINT and SIGQUIT in
>       addition to these inherited handlers.
> 
> And yes, turning on job control magically makes it work:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_11:

"When a command is in an asynchronous list, it shall inherit from the
shell a signal action of ignored (SIG_IGN) for the SIGQUIT and SIGINT
signals, and may inherit a signal mask in which SIGQUIT and SIGINT are
blocked. Otherwise, the signal actions and signal mask inherited by the
command shall be the same as those inherited by the shell from its parent
unless a signal action is modified by the trap special built-in (see
trap)."

The idea is to protect asynchronous children from keyboard-generated
signals, since all child processes belong to the same process group as
the shell, and keyboard signals are sent to all processes in the terminal's
process group.

When job control is active, all child jobs are in separate process groups,
so this is not an issue and doesn't need to happen.

That, combined with this:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28

"Signals that were ignored on entry to a non-interactive shell cannot be
trapped or reset, although no error need be reported when attempting to do
so."

means that bash doesn't allow signals that were ignored when it started,
whether that is a separate invocation or a forked child running a command,
to be changed via `trap'.  There has been some discussion on the Posix
list about exactly what "on entry" means, but nothing conclusive.

(And, FWIW, ksh93 behaves as bash does in this regard.)

Chet

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