release/src/router/busybox/shell/ash_test/ash-signals/sigint1.tests

   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