Re: Handling of SIGHUP

[Chet Ramey]

On 10/15/23 10:29 PM, Dale R. Worley wrote:
> 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.

Think of it as the difference between exiting immediately upon receipt of
a fatal signal and catching that signal to perform some processing and
going on.

When bash gets a SIGHUP, especially as an interactive shell, it does some
cleanup to the terminal and process groups, and tries to do things like
saving interactive history and running the EXIT trap (because people want
their history saved when they hit the `close' button on their terminal
emulator), but it's not a `normal' exit. In fact, the shell resets the
SIGHUP disposition to SIG_DFL and resends the signal to itself.
> 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.

It is not. The only thing that's run `during the processing of the HUP'
is `:'.

> I have not tested to see when SIGHUP is resent to child jobs. 

It is not, since the shell does not exit on SIGHUP.

> It seems to me that the documentation needs to be tweaked to explain how
> trap of SIGHUP interacts with the default SIGHUP processing.

They don't interact at all. If you trap SIGHUP, you execute the trap.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/