helpThe GNU Bourne-Again SHell - Support: sr #108721, SIGINT trap not executing properly...


sr #108721: SIGINT trap not executing properly when commands interrupted; strange interaction with loops.

Submitter:  Kaz Kylheku <kkylheku>
Submitted:  Thu 08 Jan 2015 10:36:52 PM UTC
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Fri 13 Nov 2015 04:29:25 PM UTC, comment #2: 

The issue is whether or not a command dying from SIGINT should cause the shell to act as if it received the SIGINT and break out of the loop.

bash-4.4 will break the loop.

Chet Ramey <chet>
Project Administrator
Wed 25 Mar 2015 10:27:24 AM UTC, comment #1: 

The issue here is that your trap is being inherited by cat. Please see this:

dualbus@yaqui:~/local/src/gnu/bash$ PS1='\$ '
$ (trap "" INT; python -c 'import signal; print {signal.SIG_DFL: "dfl", signal.SIG_IGN: "ign"}[signal.getsignal(2)'])
$ (trap - INT; python -c 'import signal; print {signal.SIG_DFL: "dfl", signal.SIG_IGN: "ign"}[signal.getsignal(2)'])
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyError: <built-in function default_int_handler>

As you can see, the python process inherits the status of the shell trap for the SIGINT signal. So, what this means is that in your while loop, since cat is the foreground process, it will receive the SIGINT, and since it's not doing the default action for the signal (because it inherited another), it will just ignore the signal.

I'm not aware of any workarounds, but this is just how UNIX works.

Eduardo Bustamante <dualbus>
Thu 08 Jan 2015 10:36:52 PM UTC, original submission:  

The following reproduces with Bash 4.3, patch 30, in an interactive session.

Suppose we install a SIGINT trap as follows:

    $ func() { echo; echo FUNC; }
    $ trap func SIGINT

Now if we type ^C at the prompt, we get:

    $ ^C


If we interrupt a command like cat, we do not see FUNC: the trap does not run. However, the interrupt is successful.

    $ cat

If we interrupt a loop consisting of just built in commands, this happens:

    $ while true ; do : ; done


Unlike the cat case, interrupt works, and the trap is also executed.

Now suppose we combine the two and make a loop which calls cat:

    $ while true ; do cat ; done

Oops! We cannot interrupt this because SIGINT is trapped, yet there is no evidence of the execution of the trap. We must use SIGTSTP to get out of the situation:

    [1]+  Stopped                 cat
    $ kill %1
    [1]+  Terminated              cat

I don't know what the expected behavior should be. The possibilities which suggest themselves to me:

1. Trapped means that the handler takes the whole responsibility for the SIGINT, and so overrides interrupting behavior. No command can be interrupted if the trap is in effect: the trap prints its message, and then the command resumes. External commands which receive the SIGINT from the kernel do whatever they want; if they terminate, then the shell handles that. Built in commands such as infinite loops become uninterruptible, but the trap handler's message is reliably seen.

2. Trapped means, in interactive mode at least, that the handler is invoked, and that the command is aborted via a transfer back to the top level interactive loop. We consistently see the message printed by the handler, and are consistently brought back to the interactive command prompt.

Kaz Kylheku <kkylheku>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by dualbus (Posted a comment)
  • -email is unavailable- added by kkylheku (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-13 chet StatusNone Done

    Back to the top

    Powered by Savane 3.9