The basic explanation of how Bash handles SIGUP is (in 5.1):
The shell exits by default upon receipt of a SIGHUP. Before exiting,
an interactive shell resends the SIGHUP to all jobs, running or
stopped. Stopped jobs are sent SIGCONT to ensure that they receive the
SIGHUP.
Bash doesn't execute .bash_logout in this situation, although that isn't
made entirely clear:
When an interactive login shell exits, or a non-interactive login shell
executes the exit builtin command, bash reads and executes commands
from the files ~/.bash_logout and /etc/bash.bash_logout, if the files
exists.
However, if I set a trap on SIGHUP, Bash's behavior seems to change. In
particular, if I set a no-op trap:
trap ':' SIGHUP
then .bash_logout *is* run during the processing of the HUP.
I have not tested to see when SIGHUP is resent to child jobs. The
documentation suggests that SIGHUP is resent if Bash exits on SIGHUP,
but if Bash exits normally, SIGHUP is sent only if huponexit is set, and
huponexit seems to be unset by default. But it's possible that behavior
interacts with trap as well.
It seems to me that the documentation needs to be tweaked to explain how
trap of SIGHUP interacts with the default SIGHUP processing.
Dale
