From: Philippe Altherr <philippe.altherr@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] More ERR_EXIT (was Re: Tests RE behavior of ERR_EXIT)
Date: Wed, 16 Nov 2022 08:56:44 +0100 [thread overview]
Message-ID: <CAGdYchsH4jYQqvhP+weT6UVB1GkUQcDyb-g+NTWZsK5CK6856Q@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7aRMufyzB6KZMtQ2GE0ztXFQjF0RAkqU2fhx8zxKpGhFA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3276 bytes --]
>
> [...] 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
[-- Attachment #2: Type: text/html, Size: 5372 bytes --]
next prev parent reply other threads:[~2022-11-16 7:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-12 22:16 Philippe Altherr
2022-11-13 3:59 ` Philippe Altherr
2022-11-13 4:11 ` Bart Schaefer
2022-11-13 13:55 ` Philippe Altherr
2022-11-13 14:24 ` Philippe Altherr
2022-11-13 15:45 ` Philippe Altherr
2022-11-13 16:52 ` Bart Schaefer
2022-11-13 16:45 ` Bart Schaefer
2022-11-13 16:53 ` Bart Schaefer
2022-11-13 18:37 ` Philippe Altherr
2022-11-13 20:55 ` Philippe Altherr
2022-11-13 22:27 ` Bart Schaefer
2022-11-13 23:10 ` Lawrence Velázquez
2022-11-13 22:12 ` Bart Schaefer
2022-11-15 1:11 ` Bart Schaefer
2022-11-15 7:01 ` [PATCH] Even more ERR_EXIT (was Re: More ERR_EXIT " Bart Schaefer
2022-11-15 7:30 ` Philippe Altherr
2022-11-15 19:50 ` Philippe Altherr
2022-11-15 7:26 ` [PATCH] More ERR_EXIT (was " Philippe Altherr
2022-11-15 19:18 ` Philippe Altherr
2022-11-15 21:08 ` Bart Schaefer
2022-11-16 2:41 ` Lawrence Velázquez
2022-11-16 6:31 ` Philippe Altherr
2022-11-16 5:51 ` Bart Schaefer
2022-11-16 7:56 ` Philippe Altherr [this message]
2022-11-16 14:21 ` Philippe Altherr
-- strict thread matches above, loose matches on Subject: below --
2022-11-09 5:29 Tests RE behavior of ERR_EXIT Bart Schaefer
2022-11-10 5:22 ` [PATCH] More ERR_EXIT (was Re: Tests RE behavior of ERR_EXIT) Bart Schaefer
2022-11-10 5:47 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGdYchsH4jYQqvhP+weT6UVB1GkUQcDyb-g+NTWZsK5CK6856Q@mail.gmail.com \
--to=philippe.altherr@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).