Re: Zsh spins in endless loop with SIGHUP + read in zshexit

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

> On 13 May 2021 at 22:37 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Thu, May 13, 2021 at 11:44 AM Peter Stephenson
> <p.w.stephenson@xxxxxxxxxxxx> 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.
>