Re: Turning off job control doesn't make async jobs ignore SIGINT

[Chet Ramey]

AnMaster wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-pc-linux-gnu-gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
> -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -march=k8 -pipe -O2 -msse3
> uname output: Linux tux 2.6.22-gentoo-r5 #1 Mon Aug 27 18:24:02 CEST 2007 
> x86_64 AMD Sempron(tm) Processor 3300+ AuthenticAMD GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 3.2
> Patch Level: 17
> Release Status: release
> 
> Description:
> From man bash:
>        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.   Commands  run  as  a result of command substitution ignore 
> the keyboard-generated job control signals
>        SIGTTIN, SIGTTOU, and SIGTSTP.
> 
> This doesn't seem to be the case. When job control is not in effect, async 
> jobs still get SIGINT sent to them even if
> SIGINT is sent to the main process.

I can't reproduce this with bash-3.2.25 on Mac OS X.  Using the following
somewhat simplified version of your script:

set +m
echo $$

trap 'echo INT; ps auxww | grep $pid ; echo QUIT >&4' INT

{
trap 'echo subshell INT; exit 1' INT;
sleep 100
} &
pid=$!

exec 4>/tmp/OUT

wait
echo after wait

cat /tmp/OUT

kill -0 $pid
kill $pid

rm -f /tmp/OUT
exit 0

I get some variation of the following output whether I use ^C or send
SIGINT from another shell:

19591
INT
chet     19592   0.0 -0.0    29232    404  p1  S+    9:35PM   0:00.00
../bash-3.2-patched/bash ./x3
chet     19595   0.0 -0.0    27372    428  p1  S+    9:35PM   0:00.01 grep
19592
after wait
QUIT
./x3: line 22: 19592 Terminated              { trap 'echo subshell INT;
exit 1' INT; sleep 100; }

A system call tracer would probably give you more insight into what's
happening to your script.  If I had to guess, I'd guess that nc is
terminating because the process at the other end of the named pipe
terminates before nc reads from it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/