bug-bash
[Top][All Lists]
Advanced

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

Re: Bug where SIGINT trap handler isn't called


From: Chet Ramey
Subject: Re: Bug where SIGINT trap handler isn't called
Date: Thu, 30 Jul 2015 14:23:15 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1

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/



reply via email to

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