Re: using trap function to cleanup and exit?

[Greg Klanderman <gak@xxxxxxxxxxxxxx>]

Hi Bart, thank you for your reply and sorry for the delay getting back
to you.  I haven't had enough time to fully explore this yet, and
won't for at least another week.  Some replies inline..

>>>>> On April 10, 2022 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> On Sun, Apr 10, 2022 at 9:30 AM Greg Klanderman <gak@xxxxxxxxxxxxxx> wrote:
>> 
>> I've tried both exit and return in a list trap, and am not seeing the
>> script exit.

> The rules for traps and child processes are a bit hard to follow.  If
> a signal trap is set to something other than the default in the
> parent, then that signal is supposed to be blocked in the child, which
> means the signal won't be propagated from the parent to the child.

> The following options also control signaling behavior:

> MONITOR - off by default in scripts, and when off, causes background
> jobs to be left running when the shell exits.

Right, I expect background processes to be left running by default.

> POSIX_JOBS - off by default in native mode, when on forces MONITOR off
> in subshells

> HUP - on by default, and if MONITOR is also set, causes child
> processes to be sent a SIGHUP when the parent exits

> TRAPS_ASYNC - off by default, when on the parent handles signals
> immediately, otherwise foreground children must exit first

This TRAPS_ASYNC default seems to reflect what the page Larry linked
to described for bash.

The script I posted is using /bin/zsh -f, so TRAPS_ASYNC should be
off, but I do see a trap run immediately, when the script is running

<external-program> | <shell-function>

at the time the signal is received.

Is the <external-program> considered a foreground child?

> POSIX_TRAPS - off in native mode, modifies the behavior of the EXIT
> trap (on in sh/bash/ksh emulations)

> LOCAL_TRAPS - off in native mode, saves trap state on function entry
> and restores on function return

>> Also, is exit intentionally disabled from within a trap function?

> No; there was a bugfix for a related thing in 5.6.1 and a couple of
> other exit-from-a-trap tweaks involving loop structures that are
> pending the next release, but exit from a trap should work (and does
> in some simple tests I did).  Do you have a simple example, and are
> you sure you're not seeing the effects of some of the above options?

See the #!/bin/zsh -f script I posted originally - I think it is
fairly simple, and zsh -f should ensure the options are in a known
default state.

When TRAPTERM uses 'exit' rather than 'return', the script does not
exit after receiving SIGTERM.  With 'return', the script does exit,
but the <external-program> in

<external-program> | <shell-function>

remains running.  Since it was not backgrounded, I'm not sure how to
make sense of the expected behavior based on the options you described
above.

It seems to me like it should be killed, as there was no way to
capture its PID in order to arrange for it to be killed at exit.

thank you,
Greg

>> I didn't expect that, even with the special return handling.  So,
>> there is no way to exit 0 from a trap, since that is interpreted as
>> the signal having been handled, and wanting to continue executing?

> Again I'm not seeing this.  If I exit zero from an INT trap, the exit
> status of the interrupted script is zero.  However, if I exit from an
> exit trap, the status of the exit trap is ignored and I get the status
> from before it was called, e.g., killing a script with SIGINT always
> returns 130 even when TRAPEXIT calls exit with a different value.  I'm
> not sure that's clearly documented anywhere.

>> With no traps of either type, should the child sleep remain after the
>> script is killed by a signal?

> See above RE signal options.  Probably yes.