Handling of SIGHUP

[Dale R. Worley]

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