Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11278

Re: Bug where SIGINT trap handler isn't called

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: Bug where SIGINT trap handler isn't called
Date 2015-07-30 14:23 -0400
Message-ID <mailman.7662.1438280619.904.bug-bash@gnu.org> (permalink)
References <55919F53.7030409@fau.de> <5591E281.1020708@case.edu> <55A72D84.2040405@fau.de> <55AEF97A.5020608@case.edu> <55B4331A.4090804@fau.de>

Show all headers | View raw


On 7/25/15 9:08 PM, Patrick Plagwitz wrote:

> I think command substitution has two issues. Those are because
> set_job_and_cleanup isn't called for the single child made for comsub.
> (1) The bug that was fixed in the discussion you linked is still in for
> comsub waits:
> $ bash -c 'while [ "$(exec >&-; sleep 0.001)" = "" ]; do :; done'
> sometimes requires two ^Cs to stop.
> The reason seems to be the same race condition described in
> http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00073.html
> and in your and in my last mail. Checking last_command_exit_value ==
> (128 + SIGINT) in command_substitute reflects the way the now-called
> child_caught_sigint was determined before the patch made during the
> discussion (i.e. it doesn't implement the heuristics).

I see what you're saying, but I tested that and it doesn't make a
difference.  In the (admittedly very few) cases where that command
took two ^Cs to kill, child_caught_sigint was always 1.  The issue
is the same as it always was: the ^C happens after the child runs
`exit(0)' and before the parent's waitpid call returns.  That causes
the waitpid to return with -1/EINTR, setting child_caught_sigint to 1,
and the next waitpid call picks up the 0 exit status, meaning that
it's not reset.


> (2) Running the comsub version of one of the above scripts:
> $ bash -c 'trap "echo trap; exit" INT; foo="$(exec >&-; python -c
> "import time; time.sleep(10)")"; echo foo'
> yields another result (it prints foo, not trap). This is the behavior
> the original bug report was about and you already replied to it but is
> the difference between comsub children and normal ones here intended?

Yes.  While the shell runs command substitutions synchronously, it does
not consider them foreground jobs.  The code to run a trap set on SIGINT
if the foreground job exits due to SIGINT was added as a compromise with
old behavior back in 1996 for bash-2.0 and is entrenched now.

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/

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Bug where SIGINT trap handler isn't called Chet Ramey <chet.ramey@case.edu> - 2015-07-30 14:23 -0400

csiph-web