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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
