[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG] Bash not reacting to Ctrl-C
From: |
Oleg Nesterov |
Subject: |
Re: [BUG] Bash not reacting to Ctrl-C |
Date: |
Wed, 9 Feb 2011 15:18:36 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On 02/08, Chet Ramey wrote:
>
> On 2/8/11 4:17 PM, Oleg Nesterov wrote:
>
> > Once again. If bash gets ^C and at the same time the current foreground
> > child exits normally (either because this jctl signal races with exit()
> > or because the child hooks SIGINT and exits after that) SIGINT is lost.
> >
> > set_job_status_and_cleanup() insists that WTERMSIG(child->status) should
> > be SIGINT, iow the child should be killed by the same signal. Otherwise
> > it is not going to kill itself, and the next wait_for() clears
> > wait_sigint_received.
> >
> > This all looks intentional, but this means ^C can never work reliably.
>
> It depends on what you mean by `reliably'.
Sure, I understand that it is not that simple.
> 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.
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.
However. I think the shell should react and exit. Exactly because it
runs in the same foreground process group. If the user doesn't want
this behaviour he can change the script, say,
#!./bash
trap true SIGINT
perl -we '$SIG{INT} = sub {exit}; sleep'
trap - SIGINT
echo "OK, WCE mode makes sense sometime"
sleep 100
Better yet, perhaps bash can have the new command/builtin which does
setpgid() and TIOCSPGRP before running the command.
Oleg.
- Re: [BUG] Bash not reacting to Ctrl-C, (continued)
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/11
- Re: [BUG] Bash not reacting to Ctrl-C, Oleg Nesterov, 2011/02/11
- Re: [BUG] Bash not reacting to Ctrl-C, Linus Torvalds, 2011/02/11
- Re: [BUG] Bash not reacting to Ctrl-C, Linus Torvalds, 2011/02/11
- Re: [BUG] Bash not reacting to Ctrl-C, Oleg Nesterov, 2011/02/13
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C, Linus Torvalds, 2011/02/11
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C,
Oleg Nesterov <=
- Re: [BUG] Bash not reacting to Ctrl-C, Ingo Molnar, 2011/02/09
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C, Bob Proulx, 2011/02/09
- Re: [BUG] Bash not reacting to Ctrl-C, Oleg Nesterov, 2011/02/09
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C, Bob Proulx, 2011/02/09
- Re: [BUG] Bash not reacting to Ctrl-C, Oleg Nesterov, 2011/02/09
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28
- Re: [BUG] Bash not reacting to Ctrl-C, Chet Ramey, 2011/02/28