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.
