>
> [...] Just use ".txt" [...]


Yep, I noticed that that's what you did and that this was rendered much
better on www.zsh.org/. I will do that.

Did using localoptions here break something?


I was just about to comment on that. This was automatically reverted when I
reverted your 3 patches. And it took me a while to figure out why my new
tests in C03traps were failing. It's only after sending my patch that I
realized that you too had to fix that issue. And that you did it in a nicer
way. I will change my patch to use your fix.

I started making all my changes on the premise that "bbb: 1" was
> incorrect output.


Ah, now I understand where the misunderstanding is coming from :-(

After fix-err-exit.patch is applied, the bug.zsh
> script outputs


> aaa: 0
> bbb: 1


Which is what POSIX mandates and also what Bash does.


> So my question is, was the whole premise of the thread that started
> there, incorrect?


Yes and no :-( In my original post, I noticed two things

A) "false && true" at the top-level doesn't trigger an ERR_EXIT even though
it ends in an error and isn't part of a condition.
B) the call to fun1 doesn't trigger and ERR_EXIT while the call to fun2
does.

At that time I didn't know about POSIX, nor about its exception 3. I also
didn't know what Bash was doing (I hadn't thought about comparing Zsh with
Bash). It was quite clear to me that B was a bug (because in what world
should fun1 and fun2 behave differently?!?). So it was clear that there
should be no "ccc: 1" output. I was much less sure about A. Clearly it
wasn't doing what I wanted but it was much less clear whether it could be
qualified as a bug. And it turns out that POSIX mandates that there is NO
ERR_EXIT. So "bbb: 1" is expected.

Your current assertion is that those tests were correct all along,
> because you've reverted them back to the 5.8.1/5.9 status, so ...
> they're not a disagreement with bash?


Yes, these tests are in agreement with Bash (and POSIX). It's only when you
modify these tests to move the "false && true" and the surrounding
statement into a function that you can observe a disagreement between Zsh
5.8 and Bash.

Somewhere along the line we pivoted from "errexit isn't exiting in
> case X" to "errexit shouldn't exit in case Y"


Did we? All the bugs were always about cases where Zsh did NOT exit while
it should.

In the original thread, I mentioned that I would like to have an option
such that Zsh DOES errexit in a few cases where it currently doesn't, like
for example after the top-level "false && true" or after "false" in "if
false; true; then true fi". You and Lawrence opposed that. That's the only
instance of "errexit shouldn't exit in case Y" that I can remember of. Were
there others?

(given also Lawrence's remarks RE source and eval)


That's again instances of "errexit isn't exiting in case X".

I'm not sure we've yet resolved
> that any of the approaches to Y are satisfactory for X.


If by this you refer to your and Lawrence's opposition to some of the
changes that I wished, then the answer is no. Neither my patch nor the
patching of the newly discovered bugs (source and eval) will give me what I
wish. I will have to come back to that later and try to better explain what
I would like to get and why.

Philippe