Re: Bug where SIGINT trap handler isn't called

[Chet Ramey]

On 6/29/15 3:41 PM, Patrick Plagwitz wrote:

> Bash Version: 4.3
> Patch Level: 39
> Release Status: release
> 
> Description:
> There's a bug that happens when waiting for a child process to complete
> (via wait_for in jobs.c) that isn't part of a job, like command
> substitution subshells. If a SIGINT is caught by the
> wait_sigint_handler, the handler sets the wait_sigint_received flag
> which is checked in set_job_status_and_cleanup. But
> set_job_status_and_cleanup is called from waitchld only if the pid
> belongs to a process that is part of a job. The result is that a SIGINT
> trap, if it exists, is not called if a SIGINT is received while waiting
> for a comsub subshell.

This isn't exactly correct.  The SIGINT trap will be called if the process
in the command substitution exits due to SIGINT.  For instance, if you
change the assignment to something like:

foo=$(sleep 20 >&- )
or
foo=$(exec 2>&- ; sleep 20)

both of which I think correctly reproduce the python command, the SIGINT
trap will execute.

This is another case of the scenario most recently described in

http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00108.html

In this case, python appears to catch the SIGINT (it looks like a
KeyboardInterrupt exception), print the message, and exit with status 1.

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/