help / color / mirror / code / Atom feed
From: Greg Klanderman <gak@klanderman.net>
To: zsh-workers@zsh.org
Subject: Re: using trap function to cleanup and exit?
Date: Thu, 14 Apr 2022 01:13:23 -0400	[thread overview]
Message-ID: <874k2wz1qk.fsf@lwm.klanderman.net> (raw)
In-Reply-To: <db607f81-53d7-4294-bead-c76bed491217@www.fastmail.com> (Lawrence =?iso-8859-1?Q?Vel=E1zquez's?= message of "Sun, 10 Apr 2022 14:15:15 -0400")

>>>>> On April 10, 2022 Lawrence Velázquez <larryv@zsh.org> wrote:

> On Sun, Apr 10, 2022, at 12:30 PM, Greg Klanderman wrote:
>> With no traps of either type, should the child sleep remain after the
>> script is killed by a signal?

> Child processes are not automatically terminated if their parent
> dies.  In general you have to handle this yourself (for example,
> https://mywiki.wooledge.org/SignalTrap#When_is_the_signal_handled.3F).
> I don't know if zsh has some special sauce to streamline this, as
> I rarely write scripts that spawn long-running processes.

Thank you Larry, of course that link is describing bash, not zsh, and
it's not immediately clear if they do/should behave the same in this

It does say that if an external foreground command is executing in
bash, that signals will not be handled until the command terminates.

And so the workaround is to background the command, in which case that
command will not be killed when the script is killed.  This is fine,
because you have the ability to capture the PID when you background
it, and so can handle killing it if you so desire.

The zsh script I posted has a foreground sleep, which does not seem to
prevent a signal from being handled as described for bash.  But with a
foreground command you have no ability to handle killing it when you
die, so it would only make sense to me for zsh to do that.

I need to study this and what Bart wrote a bunch more, but
unfortunately will not be able to do so for at least another week.

thank you,

  reply	other threads:[~2022-04-14  5:14 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 [this message]
2022-04-10 20:49       ` Bart Schaefer
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=874k2wz1qk.fsf@lwm.klanderman.net \
    --to=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).