Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: exit_function - strange behavior

Am 01.11.21 um 00:52 schrieb Bart Schaefer:
On Mon, Oct 25, 2021 at 5:53 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

There's definitely a bug in this somewhere because if the last command
executed by the final subshell [is] an anonymous function call:

zsh -fc '...; ( () { return 123 } )'

then the zshexit hook is NEVER called.

When an anonymous function (or probably any function) calls "exit", we
pass through this bit of code in builtin.c bin_break():

5719             *
5720             * If we are already exiting... give this all up as
5721             * a bad job.
5722             */
5723            if (stopmsg || (zexit(0, ZEXIT_DEFERRED), !stopmsg)) {
5724            retflag = 1;
5725            breaks = loops;
5726            exit_pending = 1;
5727            exit_level = locallevel;
5728            exit_val = num;

With ZEXIT_DEFERRED, zexit() always bails out here:

5842     /* Positive shell_exiting means we have been here before */
5843     if (from_where == ZEXIT_DEFERRED ||
5844         (shell_exiting++ && from_where != ZEXIT_NORMAL))
5845         return;

We then eventually call zexit(exit_val, ZEXIT_NORMAL) from doshfunc().

If instead the function calls "return 123" and is the last command in
the subshell, we pass through this branch of execcmd_exec():

4239     if (forked) {
4240         /*
4241          * So what's going on here then?  Well, I'm glad you asked.
4263          */
4264         for (i = 0; i < 10; i++)
4265             if (fdtable[i] != FDT_UNUSED)
4266                 close(i);
4267         closem(FDT_UNUSED, 1);
4268         if (thisjob != -1)
4269             waitjobs();
4270         _realexit();
4271     }

The call to _realexit() bypasses the hook.  This is the expected
behavior for "falling off the end" of a subshell, rather than
explicitly "exit"-ing.

However, in
   zsh -fc '( () { return 123 } )'
the parent shell optimizes away the subshell and we arrive here:

3596             /*
3597              * If we are in a subshell environment anyway, say
we're forked,
3598              * even if we're actually not forked because we know the
3599              * subshell is exiting.  This ensures SHLVL reflects
the current
3600              * shell, and also optimises out any save/restore we'd need to
3601              * do if we were returning to the main shell.
3602              */
3603             if (type == WC_SUBSH)
3604                 forked = 1;

This should not happen when there is an exit trap or an exit hook, I
think?  However, I'm not following the comment reference to SHLVL --
why would it not reflect the correct thing?  I suppose the actual
correct thing is higher up the call stack, where we should not assert
that the subshell is exiting if the parent shell still has traps or
hooks to process, so that we really have forked here.

As to this:

You can avoid that by having the subshell end with "return 123"
instead of "exit 123", except for some reason (possibly a bug) when
the -c option is used in which case return behaves like exit again.

bin_break() treats "return" as synonymous with "exit" here:

5683     case BIN_RETURN:
5684         if ((isset(INTERACTIVE) && isset(SHINSTDIN))
5685             || locallevel || sourcelevel) {
5699             return lastval;
5700         }
5701         zexit(num, ZEXIT_NORMAL);       /* else treat return as
logout/exit */

To Tycho's original question, this means there is no way to have an
exit hook or trap called exactly when the original shell exits.  You
can't forcibly finish a subshell before it "falls off the end" without
possibly invoking the trap and hook, and you can't even reliably test
$ZSH_SUBSHELL inside the hook, because the parent might optimize out a
fork without decrementing that.

[[ $sysparams[pid] = $$ ]] almost gets there, except that you can't
assure the hook itself won't be skipped by a function that calls exit.

Bart, thanks for diving into this, I hope it can be fixed. I just wanted to point out that the documentation of $ZSH_SUBSHELL needs to be fixed as well:


Readonly integer. Initially zero, incremented each time the shell forks to create a subshell for executing code. Hence ‘(print $ZSH_SUBSHELL)’ and ‘print $(print $ZSH_SUBSHELL)’ output 1, while ‘( (print $ZSH_SUBSHELL) )’ outputs 2.

So $ZSH_SUBSHELL may also be incremented, if the shell did _not_ fork:

% zsh -fc 'zmodload zsh/system; echo parent_pid: $$; echo parent_subshell $ZSH_SUBSHELL ; ( echo sysparams_pid: $sysparams[pid]; read -d " " pid < /proc/self/stat; echo proc_pid: $pid; echo child_subshell: $ZSH_SUBSHELL ; exit 123 )'
parent_pid: 20562
parent_subshell 0
sysparams_pid: 20562
proc_pid: 20562
child_subshell: 1

Anyway, I think it is ok for $ZSH_SUBSHELL to be inconsistent with $sysparams[pid] as the fork-optimization is an implementation detail and most users probably want to know whether being in enclosed '( )'.

Messages sorted by: Reverse Date, Date, Thread, Author