Re: [BUG] Bash not reacting to Ctrl-C

[Chet Ramey]

On 2/9/11 9:18 AM, Oleg Nesterov wrote:

>> Consider a script that runs
>> emacs, then does other processing when emacs completes.  Emacs uses SIGINT
>> internally to interrupt editing commands, but handles it and does not exit
>> as a result.  Since emacs is run from a script, and job control is not
>> enabled, the shell receives the SIGINT also, because it is in the
>> terminal's foreground process group.  Should the shell abort the script
>> when emacs exits?
> 
> In my opinion - it should. But yes, I know almost nothing about jctl
> (at least the non-kernel part), and I agree this behaviour can confuse
> a user too.

OK.  We're not going to agree on this.  (And it has nothing to do with
job control.)

> That is why I provided another test-case, let me repeat it:
> 
>       #!./bash
> 
>       perl -we '$SIG{INT} = sub {exit}; sleep'
> 
>       echo "Hehe, I am going to sleep after ^C"
>       sleep 100
> 
> If a user presses ^C the shell can't know what he wants, kill the
> script or send the signal to the current job.

That's not quite it.  The shell shouldn't assume that it should react
to the SIGINT because it's not the foreground program to which the user
typed ^C.  That program gets to make the decision.  If it doesn't alter
the default, it will exit due to the SIGINT and the shell will react
accordingly.  If it does, the shell will not second-guess it.

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/