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