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