Re: shell trap vs inherited signal dispositions

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 2 May 2025 15:50:31 +0300
    From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
    Message-ID:  <aBS_l-1o8sPrLHSX%snips.stderr.spb.ru@localhost>

  | When run under nohup bash prints that SIGHUP is ignored (empty
  | string):
  |
  |   $ rm -f nohup.out; nohup bash -c 'trap -p'; cat nohup.out
  |   sending output to nohup.out
  |   trap -- '' SIGHUP
[...]
  | But sh prints that SIGHUP has the default disposition:
[...]
  | So I would expect our shell's trap -p to also print trap -- '' SIGHUP
  | in a non-interactive shell under nohup.  Do I miss something here?

It is a difference of opinion as to what trap -p is intended to report.
That is, the OS signal state, or the shell trap (condition) state.

Or perhaps it is a difference of opinion as to what the default state
of traps is intended to be.

sh by default has all traps in their default state, until a trap command
causes that to be altered (and traps can be set on conditions where the
standard does not permit the shell to alter the signal state) and trap -p
reports the state of the shell's traps, the assumption being that
the point of trap -p is so traps can be saved and restored to their
current state, should a temporary alteration be required (that is,
what a bare "trap" was originally intended to do, but fails).

In sh (bash as well I think) a signal being ignored (or even caught) does
not mean there is a trap set (or not) to achieve a similar effect.

bash is trying to equate traps with signals, which they really aren't
(aside from anything else, there's no EXIT signal, and bash has several
more like that) - signals are just the mechanism the shell uses to
implement (some) traps.

POSIX doesn't say which is intended.

kre