RE: ctrl-c does not send INT to all processes under foreground job

[Ryan Ruan]

" bash doesn't do anything until the child exits" --- yes, that  is exactly 
what I have observed.
Thank you very much for your exclamation, Ramey.

/br
Ruan

-----Original Message-----
From: Chet Ramey [mailto:chet.ramey@case.edu] 
Sent: 2014年3月19日 21:51
To: Ryan Ruan; bug-bash@gnu.org
Cc: chet.ramey@case.edu
Subject: Re: ctrl-c does not send INT to all processes under foreground job

On 3/19/14 12:07 AM, Ryan Ruan wrote:
> Hello, guys:
> 
> It is said that "ctrl-C sends INT to ALL processes under foreground job", but 
> i found a weird phenomenon.
> I have not read source code yet, but it does not seem to ascribe to what 
> specification says.
> 
> Test code is like:
> 
> 1              trap "echo hello world $1" 2
> 2              sleep 10000
> 3              /bin/bash $0 $(( $1 + 1 ))
> 4              echo "$1 go to sleep"
> 5              sleep 1000
> 6              echo "$1 exit "
> 
> 
> When I run ./test.sh on the console, the process (/bin/bash test.sh) is stuck 
> at line 2.
> Then I input Ctrl-C, the result is that the code is interrupted at line 2 and 
> goes to execute line 3, thus generate a new process (/bin/bash test.sh 1).
> At the same time, the first process (/bin/bash test.sh) is stuck at line 3 
> waiting for process '/bin/bash test.sh 1' to finish.
> At this time, I input Ctrl-C again, and generate process '/bin/bash test.sh 
> 2', and i think process '/bin/bash test.sh 1' SHOULD BE SENT  signal INT now. 
> So I kill process '/bin/bash test.sh 2' by doing 'kill -9 <pid>'.
> What amazes me is that process '/bin/bash test.sh 1' did not trap INT this 
> time, because "hello world 1" is not printed out. So it seems the process did 
> not receive INT before.
> How can this be? Is it a bug?

This is another instance of the question "what does bash do with a SIGINT it 
receives while waiting for a foreground process?"  The answer is that it allows 
the child to decide what to do and responds accordingly: if the child exits due 
to being killed by the SIGINT, bash acts as if it received the SIGINT; if the 
child decides to trap it, do something else and not resend the SIGINT to 
itself, bash will effectively discard it.  In any case, bash doesn't do 
anything until the child exits.

There is a fairly long explanation of the issue at 
http://www.cons.org/cracauer/sigint.html.

This has come up in several past discussions on bug-bash, some quite heated 
(especially the first link below, which involved Linus Torvalds and several 
Linux kernel developers):

http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00050.html
http://lists.gnu.org/archive/html/bug-bash/2013-02/msg00088.html

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/