bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGINT handling


From: Stephane Chazelas
Subject: Re: SIGINT handling
Date: Mon, 21 Sep 2015 10:48:07 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

2015-09-19 21:36:28 +0100, Stephane Chazelas:
> 2015-09-18 16:14:39 +0100, Stephane Chazelas:
> [...]
> > In:
> > 
> > bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> > 
> > If I press Ctrl-C, I still see "hi".
> [...]
> 
> Jilles provided with the explanation at
> http://unix.stackexchange.com/a/230731
> 
> with a link to:
> http://www.cons.org/cracauer/sigint.html
[...]

Note that bash (and ksh, contrary to FreeBSD sh) is not
consistent in its handling of that "WCE" (for "wait and
cooperative exit") approach in that pressing ^C in:

bash -c '
  var=$(sh -c "trap \"\" INT; sleep 3; echo result)
  echo "$var"
'

kills bash, leaving the "sh" and "sleep" running unattended in
background.

Same for:

bash -O lastpipe -c '
  sh -c "trap \"\" INT; sleep 3; echo test" | read var; echo done'

One could also argue, that to be consistent, SIGTSTP and SIGQUIT
should be treated similarly (strangely enough
http://www.cons.org/cracauer/sigint.html doesn't mention SIGTSTP).

I'm not sure I prefer that WCE approach over WUE. Wouldn't it be
preferable that applications that intercept SIGINT/QUIT/TSTP for
anything other than clean-up before exit/suspend implement job
control themselves instead (like vi's :! should create a process
group and make that the foreground process group of the
terminal so pressing ^C in sh -c vi, :!sleep 10, only sends the
SIGINT to sleep)?

-- 
Stephane



reply via email to

[Prev in Thread] Current Thread [Next in Thread]