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.

Submitted by:  Kaz Kylheku <kkylheku>
Submitted on:  Thu 08 Jan 2015 10:36:52 PM UTC  
Category: NonePriority: 5 - Normal
Severity: 3 - NormalStatus: Done
Privacy: PublicAssigned to: None
Open/Closed: OpenOperating System: None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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 File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 13 Nov 2015 04:29:25 PM UTCchetStatusNone=>Done

    Back to the top

    Powered by Savane 3.1-cleanup1