When Bash is interactive, in the absence of any traps,
it ignores SIGTERM
(so that ‘kill 0’ does not kill an interactive shell),
and catches and handles SIGINT
(so that the wait builtin is interruptible).
When Bash receives a SIGINT, it breaks out of any executing loops.
In all cases, Bash ignores SIGQUIT.
If job control is in effect (see Job Control), Bash
ignores SIGTTIN, SIGTTOU, and SIGTSTP.
The trap builtin modifies the shell’s signal handling, as
described below (see Bourne Shell Builtins.
Non-builtin commands Bash executes have signal handlers set to the
values inherited by the shell from its parent,
unless trap sets them to be ignored, in which case the child
process will ignore them as well.
When job control is not in effect, asynchronous commands
ignore SIGINT and SIGQUIT in addition to these inherited
handlers.
Commands run as a result of
command substitution ignore the keyboard-generated job control signals
SIGTTIN, SIGTTOU, and SIGTSTP.
The shell exits by default upon receipt of a SIGHUP.
Before exiting, an interactive shell resends the SIGHUP to
all jobs, running or stopped.
The shell sends SIGCONT to stopped jobs to ensure that they
receive the SIGHUP
(See Job Control, for more information about running and stopped jobs).
To prevent the shell from sending the SIGHUP signal to a
particular job, remove it from the jobs table with the disown
builtin (see Job Control Builtins) or mark it
not to receive SIGHUP using disown -h.
If the huponexit shell option has been set using shopt
(see The Shopt Builtin), Bash sends a SIGHUP to all jobs when
an interactive login shell exits.
If Bash is waiting for a command to complete and receives a signal
for which a trap has been set,
it will not execute the trap until the command completes.
If Bash is waiting for an asynchronous command via the wait builtin,
and it receives a signal for which a trap has been set,
the wait builtin will return immediately with an exit status
greater than 128, immediately after which the shell executes the trap.
When job control is not enabled, and Bash is waiting for a foreground
command to complete, the shell receives keyboard-generated signals
such as SIGINT (usually generated by ‘^C’) that users
commonly intend to send to that command.
This happens because the shell and the command are in the same process
group as the terminal, and ‘^C’ sends SIGINT to all processes
in that process group.
Since Bash does not enable job control by default when the
shell is not interactive,
this scenario is most common in non-interactive shells.
When job control is enabled, and Bash is waiting for a foreground command to complete, the shell does not receive keyboard-generated signals, because it is not in the same process group as the terminal. This scenario is most common in interactive shells, where Bash attempts to enable job control by default. See Job Control, for a more in-depth discussion of process groups.
When job control is not enabled, and Bash receives SIGINT
while waiting for a foreground command, it waits until that foreground
command terminates and then decides what to do about the SIGINT:
SIGINT, Bash concludes
that the user meant to send the SIGINT to the shell as well,
and acts on the
SIGINT
(e.g., by running a SIGINT trap,
exiting a non-interactive shell,
or returning to the top level to read a new command).
SIGINT, the program
handled the SIGINT itself and did not treat it as a fatal signal.
In that case, Bash does not treat SIGINT as a fatal signal,
either, instead assuming that the SIGINT was used as part of the
program’s normal operation (e.g., emacs uses it to abort editing
commands) or deliberately discarded.
However, Bash will run any
trap set on SIGINT, as it does with any other trapped signal it
receives while it is waiting for the foreground command to
complete, for compatibility.
When job control is enabled, Bash does not receive keyboard-generated
signals such as SIGINT
while it is waiting for a foreground command.
An interactive shell does not pay attention to the SIGINT,
even if the foreground command terminates as a result, other than noting
its exit status.
If the shell is not interactive, and
the foreground command terminates due to the SIGINT,
Bash pretends it received the SIGINT
itself (scenario 1 above), for compatibility.