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'. 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?
That's the key example in Martin's long(ish) explanation of the issue.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
