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

Re: [PATCH] More ERR_EXIT (was Re: Tests RE behavior of ERR_EXIT)



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@xxxxxxxxx> 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



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