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.
pws
> 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
> DEFERRED.
>
> 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.
>
next prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* 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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.vuxu.org/mirror/zsh/
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).