[Top][All Lists]

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

Re: SIGINT kills interactive shell from dot script

From: Martijn Dekker
Subject: Re: SIGINT kills interactive shell from dot script
Date: Tue, 8 Nov 2016 18:50:13 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Op 08-11-16 om 14:38 schreef Chet Ramey:
> On 11/7/16 7:54 AM, Martijn Dekker wrote:
>> But it's really helped that bash turns out to have another unique
>> behaviour: apparently, bash refuses to ignore SIGINT on interactive
>> shells. So, for interactive bash, the workaround is simply to avoid
>> using "trap - INT" to unignore the signal.
> What do you mean? If you run 'trap "" SIGINT' in an interactive shell,
> bash will let you happily pound on ^C on your keyboard all day long
> without doing anything.

Some more experimenting showed inconsistent behaviour, so it's another
bug, not a feature. I had misinterpreted the behaviour as a feature due
to wishful thinking, because it looked so convenient as a workaround for
the interactive-shell-exits-on-SIGINT bug in my shell library. <sigh>

Here's what I've been able to determine so far. SIGINT fails to be
ignored on interactive shells if both of the following two conditions
are met:
- the SIGINT trap is non-empty (i.e. contains a command, even a simple
':' will do);
- the command(s) to be interrupted are not issued on the same command
line as the command to set the SIGINT trap.

Examples follow (using POSIX code so you can test it on any other shell).

Works as expected: The 'trap' command is on the same command line as the
loop. The signal is properly ignored, the trap is properly executed
repeatedly on pressing Ctrl+C.

$ trap 'echo INT' INT; i=0; while [ $((i+=1)) -lt 1000000 ]; do :; done
$ echo $? $i
0 1000000

Buggy behaviour: The 'trap' command is on a separate command line.
The signal is not ignored. The trap is executed once on Ctrl+C and the
loop is interrupted.

$ trap 'echo INT' INT
$ i=0; while [ $((i+=1)) -lt 1000000 ]; do :; done

$ echo $? $i
130 60985

Behaviour confirmed on bash-4.4 down to 2.05b.

Interestingly, the exit status behaviour for this bug test is
inconsistent on various bash versions. Some random ones I've tried:
- bash 4.4 produces exit status 130, the correct one for SIGINT.
- bash 4.3.39 on NetBSD produces exit status 130.
- /bin/bash 4.2.53 on Slackware 14.1 produces exit status 128.
- /bin/bash 4.1.17 on Slackware 13.37 produces exit status 128.
- /bin/bash 3.2.57 on Mac OS X 10.11.6 produces exit status 1.
- bash 2.05b produces exit status 1.

Hope this clarifies,

- M.

reply via email to

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