[...] 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