Re: Inconsistent behavior of ERR_EXIT with conditionals

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Nov 4, 2022 at 9:39 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
>> function fun1() {
>>     { false && true }
>> }
>
> [...] since the expression "false && true" as a whole evaluates to a non-zero status and doesn't appear in a position where a condition is expected, I would assume that it should trigger an exit. [...] Apparanty Zsh simply ignores non-zero statuses of conditionals if they weren't generated by the last command.

In fact, comment in exec.c says:
     * ERREXIT only forces the shell to exit if the last command in a &&
     * or || fails.  This is the case even if an earlier command is a
     * shell function or other current shell structure, so we have to set
     * noerrexit here if the sublist is not of type END.

But execcursh() unconditionally sets this_noerrexit = 1.

Does this act better?  (Hopefully I don't need an attachment for this
one-liner):

diff --git a/Src/exec.c b/Src/exec.c
index c8bcf4ee5..d11f79d90 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -451,7 +451,7 @@ execcursh(Estate state, int do_exec)
     cmdpop();

     state->pc = end;
-    this_noerrexit = 1;
+    this_noerrexit = (WC_SUBLIST_TYPE(*end) != WC_SUBLIST_END);

     return lastval;
 }

All extant tests still pass.  Does not affect how fun3 and fun4
behave, so I suspect this fix may be needed elsewhere ... there are a
bunch of similar cases for multi-line shell constructs in Src/loop.c