From: Greg Klanderman <email@example.com>
Subject: Re: using trap function to cleanup and exit?
Date: Thu, 14 Apr 2022 01:57:27 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <CAH+w=7bGcXOc5r3amBYwqV42Mg2hFsiu+HxbhbH7M2FdjgNGnw@mail.gmail.com> (Bart Schaefer's message of "Sun, 10 Apr 2022 13:49:17 -0700")
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 <email@example.com> wrote:
> On Sun, Apr 10, 2022 at 9:30 AM Greg Klanderman <firstname.lastname@example.org> 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
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
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.
>> 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.
next prev parent reply other threads:[~2022-04-14 5:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-10 15:46 Greg Klanderman
2022-04-10 15:57 ` Peter Stephenson
2022-04-10 16:12 ` Greg Klanderman
2022-04-10 16:30 ` Greg Klanderman
2022-04-10 18:15 ` Lawrence Velázquez
2022-04-14 5:13 ` Greg Klanderman
2022-04-10 20:49 ` Bart Schaefer
2022-04-10 20:55 ` Bart Schaefer
2022-04-14 5:57 ` Greg Klanderman [this message]
2022-04-14 21:29 ` Bart Schaefer
2022-04-14 23:35 ` Bart Schaefer
2022-04-17 17:08 ` Daniel Shahaf
2022-04-15 22:27 ` Bart Schaefer
2022-04-19 18:42 ` Peter Stephenson
2022-04-19 18:55 ` Peter Stephenson
2022-04-19 21:22 ` Bart Schaefer
2022-04-20 8:16 ` Peter Stephenson
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).