Here is one thing that could explain why the "where" statement is an
outlier (at least compared to the other compound commands that I have
tested so far). It's the only case where after evaluating "false && true"
you have to first evaluate a whole other command, the loop condition,
before deciding whether you trigger an ERR_EXIT for the "while". For the
other compound commands, you evaluate the "false && true" and then
immediately decide whether you trigger an ERR_EXIT for the compound command.

Here is an observation that could save some complexity. A non-zero exit
status either immediately triggers an ERR_EXIT, like in "false" or it
doesn't like in "false && true" and instead bubbles up to the first
enclosing function or subshell thanks to exception 3. Thus, compound
commands other than subshells never have to trigger an ERR_EXIT. That's a
nice and not necessarily obvious side benefit of exception 3. I wonder
whether the code was designed without that insight or maybe without knowing
about exception 3 altogether. Without exception 3, compound commands
sometimes have to trigger an ERR_EXIT and that could explain some of the
current code and behavior.

Philippe


On Sun, Nov 13, 2022 at 7:37 PM Philippe Altherr <philippe.altherr@gmail.com>
wrote:

> NOERREXIT_UNTIL_EXEC is what protects the tests between keywords "if"
>> and "then" and those between "while" and "do" from triggering
>
> ERR_EXIT.
>
>
> Really? NOERREXIT_UNTIL_EXEC is only ever set in execif. How can it impact
> the code of a while statement? There is no trace of it in execwhile. What
> am I missing?
>
> Philippe
>
>