[Top][All Lists]

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

Re: [BUG] Bash not reacting to Ctrl-C

From: Chet Ramey
Subject: Re: [BUG] Bash not reacting to Ctrl-C
Date: Mon, 28 Feb 2011 21:10:50 -0500
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

On 2/9/11 4:57 PM, Linus Torvalds wrote:
> On Wed, Feb 9, 2011 at 1:18 PM, Bob Proulx <address@hidden> wrote:
>> Since the exit status of /bin/true is ignored then I think that test
>> case is flawed.  I think at the least needs to check the exit status
>> of the /bin/true process.
>>  bash -c 'while true; do /bin/true || exit 1; done'
> The "|| exit 1" doesn't make any sense. If you seriously claim that
> that is needed for ^C to work reliably, you're just totally mistaken.
> Your whole premise that you should look at the error return code is
> total and utter crap. Lookie here:
>    while : ; do sleep 1; done
> which is *exactly* the same case, and dammit, if ^C doesn't break out
> of that loop, then the shell is a broken POS. Agreed? If you tell me
> that it needs a "|| exit 1", you're just broken.

There's a lot of heat here, and not as much light.  You are correct:
there is a race condition -- bash would have missed a SIGINT if it arrived
after the child began to exit but before the SIGINT signal handler got
restored. The shell would have noted the SIGINT but not exited because the
child did not die as a result of SIGINT.

Let's work to close, or at least tighten, any race conditions.  That's
the right fix.  The intended behavior is not up for debate.

``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]