>
> [...] That's the only instance of "errexit shouldn't exit in case Y" that
> I can remember of. Were there others?


Oh and then there was the thread about your patch where I noticed that the
ERR_EXIT was triggered too early. There I commented that in a number of
cases there should be no ERR_EXIT. Unfortunately, I didn't realize that you
had misunderstood the expected behavior. It's only later, when I prepared
my patch, that I realized that you had changed the expected exit status of
some tests.

Philippe


On Wed, Nov 16, 2022 at 8:56 AM Philippe Altherr <philippe.altherr@gmail.com>
wrote:

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