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?

  • That for and while loops are broken as though break was executed. – Ignacio Vazquez-Abrams Oct 28 '17 at 1:25
0

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 ^D

  • 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. – Johan Myréen Oct 28 '17 at 16:59
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.