2

This page says the following:

When Bash is interactive, in the absence of any traps, it ignores SIGTERM (so that `kill 0' does not kill an interactive shell), and SIGINT is caught and handled (so that the wait builtin is interruptible). When Bash receives a SIGINT, it breaks out of any executing loops.

Usually when a program receives the SIGINT signal, the program will exit. But bash does not exit when it receives the SIGINT signal, instead "it breaks out of any executing loops". What does that mean?

2
  • That for and while loops are broken as though break was executed. Commented Oct 28, 2017 at 1:25
  • Behavior of SIGINT with Bash Commented Apr 22 at 3:22

2 Answers 2

1

It means that the built-ins and loops that bash is running at that moment are aborted. To achieve the SIGINT effect on bash, use Ctrl+D

2
  • 1
    From the bash manual: "In all cases, Bash ignores SIGQUIT." Bash will interpret Ctrl-D at the start of an input line as end of input and exit, but this has nothing to do with signals. Commented Oct 28, 2017 at 16:59
  • 1
    It's Ctrl+C, not Ctrl+D. Commented Aug 20, 2022 at 14:07
1

In the end, bash is broken. The way that a shell process should process sigint, is to catch it, and to then stop all processing and wait for all pending forground processes to exit. realistically, there is no reason why SIGINT should not interrupt everything that is running in the foreground. this is why process groups were created ages ago. Every "command" that bash is given by the user should fork processes in the same pgroup and it's that pgroup that signals should be forwarded to. It should not be necessary to forward signals if pgroup is used correctly, because each process forked should have the same signal handling, by default, that bash has. nohup should cause all forked processes to have sighup == ignored.

There has been a lot of detail around the original unix shell signal handling and process relationships missed in bash. SIGINT to a shellscript in particular should flat out stop the entire shellscript, not break from loops which can just cause it to start more processing which can destroy files because previous work that did not finish due to the SIGINT.

Yes, the trap statement can help you exit more cleanly. But it was never required in original unix shell implementations. It was primarily a cleanup mechanism for temp file usage or other similar details. Now, it is required to make the shell exit when it should, and that makes it difficult to write dependable shell scripts which can easily be interrupted.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.