help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: Zsh spins in endless loop with SIGHUP + read in zshexit
Date: Fri, 14 May 2021 10:56:16 +0100 (BST)	[thread overview]
Message-ID: <979701293.98679.1620986176059@mail2.virginmedia.com> (raw)
In-Reply-To: <CAH+w=7aHn-fyZc+Z6oP=2KqCVnxe4Av-mrhjG1MM9RD27Yy-Yw@mail.gmail.com>

> On 13 May 2021 at 22:37 Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Thu, May 13, 2021 at 11:44 AM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
> >
> > I haven't looked for cases where we're disobeying "exit" from shell code
> > owing to the same logic
> So besides the one discussed already in this thread, we have:
> 1) ${unset?error message}
> 2) return at top level (bin_break + BIN_RETURN)
> 3) exit (bin_break + BIN_EXIT)
>   3a) in a shell function (ZEXIT_DEFERRED)

Focussing on this one, I tried

TRAPEXIT() { while true; do exit; done; }

and sure enough the shell is looping forever if I kill the terminal.
(Obviously, as written that's a daft thing to do, but with an appropriate
set of internal conditions it might become realistic.)

This is the sort of thing I was thinking about --- the answer is probably
going to be along the lines of "breaks = loops" etc. in that condition
at the top of zexit(), but I haven't made a patch as I suspect there's
going to be more to the can of worms.


>   3b) at top level (ZEXIT_NORMAL)
> 4) doshfunc() when not already in an exit trap
> 5) loop() when (3a) has previously happened
> 6) init_misc() for "zsh -c somecommand"
> 7) zsh_main() at end of input (can be canceled by ignoreeof)
> 8) zpty module at the end of the child thread
> 9) signal handling for HUP PIPE ALRM and if not interactive INT
> (3a) uses zexit in a comma expression, I'm surprised that doesn't
> produce a warning for a void function.  That is the only instance of
> The only time zexit() fails to _exit() is when called recursively,
> which I believe can only happen in a trap.  Possible "dangerous" cases
> when used in a trap:
> (1) could unexpectedly proceed beyond the parameter expansion into the
> subsequent shell code.
> (2,3) and by extension (4) when used in combination with an "always"
> block (this is not clear-cut) would continue the shell code.
> (8) would continue into the pty master code if a new zpty were opened.
> I haven't tested whether any of these things actually DO fail to
> _exit(), just source code examination of what comes downstream in each
> circumstance.  When there is no "always", I believe 2 and 3 correctly
> end processing of the current function scope.

  reply	other threads:[~2021-05-14  9:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 10:17 Jörg Sommer
2021-05-13 14:36 ` Daniel Shahaf
2021-07-18 19:11   ` Lawrence Velázquez
2021-07-27  3:14     ` Daniel Shahaf
2021-05-13 15:51 ` Peter Stephenson
2021-05-13 15:54 ` Bart Schaefer
2021-05-13 16:07   ` Peter Stephenson
2021-05-13 16:30     ` Bart Schaefer
2021-05-13 18:44       ` Peter Stephenson
2021-05-13 21:37         ` Bart Schaefer
2021-05-14  9:56           ` Peter Stephenson [this message]
2021-05-14 17:44             ` Peter Stephenson
2021-05-14 18:51             ` Bart Schaefer

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=979701293.98679.1620986176059@mail2.virginmedia.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@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).