help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Greg Klanderman <gak@klanderman.net>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: using trap function to cleanup and exit?
Date: Sun, 10 Apr 2022 13:49:17 -0700	[thread overview]
Message-ID: <CAH+w=7bGcXOc5r3amBYwqV42Mg2hFsiu+HxbhbH7M2FdjgNGnw@mail.gmail.com> (raw)
In-Reply-To: <87czho2967.fsf@lwm.klanderman.net>

On Sun, Apr 10, 2022 at 9:30 AM Greg Klanderman <gak@klanderman.net> 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.
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
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?

> 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.

  parent reply	other threads:[~2022-04-10 20:50 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 [this message]
2022-04-10 20:55         ` Bart Schaefer
2022-04-14  5:57         ` Greg Klanderman
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

Reply instructions:

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 \
    --in-reply-to='CAH+w=7bGcXOc5r3amBYwqV42Mg2hFsiu+HxbhbH7M2FdjgNGnw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=gak@klanderman.net \
    --cc=zsh-workers@zsh.org \


* 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).