mirror of
https://github.com/sheumann/hush.git
synced 2024-12-23 20:29:42 +00:00
42 lines
1.6 KiB
Plaintext
Executable File
42 lines
1.6 KiB
Plaintext
Executable File
# 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
|