[Top][All Lists]

[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: Mon, 29 Jun 2015 20:27:45 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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 >&- )
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


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


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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