Date: Fri, 2 May 2025 15:50:31 +0300
From: Valery Ushakov <u...@stderr.spb.ru>
Message-ID: <abs_l-1o8sprl...@snips.stderr.spb.ru>
| 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
