| # What should happen if non-interactive shell gets SIGINT? |
| |
| (sleep 1; echo Sending SIGINT to main shell PID; exec kill -INT $$) & |
| |
| # We create a child which exits with 0 even on SIGINT |
| # (The complex command is necessary only if SIGINT is generated by ^C, |
| # in this testcase even bare "sleep 2" would do because |
| # in the testcase we don't send SIGINT *to the child*...) |
| $THIS_SH -c 'trap "exit 0" SIGINT; sleep 2' |
| |
| # In one second, we (main shell) get SIGINT here. |
| # The question is whether we should, or should not, exit. |
| |
| # bash will not stop here. It will execute next command(s). |
| |
| # The rationale for this is described here: |
| # http://www.cons.org/cracauer/sigint.html |
| # |
| # Basically, bash will not exit on SIGINT immediately if it waits |
| # for a child. It will wait for the child to exit. |
| # If child exits NOT by dying on SIGINT, then bash will not exit. |
| # |
| # The idea is that the following script: |
| # | emacs file.txt |
| # | more cmds |
| # User may use ^C to interrupt editor's ops like search. But then |
| # emacs exits normally. User expects that script doesn't stop. |
| # |
| # This is a nice idea, but detecting "did process really exit |
| # with SIGINT?" is racy. Consider: |
| # | bash -c 'while true; do /bin/true; done' |
| # When ^C is pressed while bash waits for /bin/true to exit, |
| # it may happen that /bin/true exits with exitcode 0 before |
| # ^C is delivered to it as SIGINT. bash will see SIGINT, then |
| # it will see that child exited with 0, and bash will NOT EXIT. |
| |
| # Therefore we do not implement bash behavior. |
| # I'd say that emacs need to put itself into a separate pgrp |
| # to isolate shell from getting stray SIGINTs from ^C. |
| |
| echo Next command after SIGINT was executed |
