zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Philippe Altherr <philippe.altherr@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] More ERR_EXIT (was Re: Tests RE behavior of ERR_EXIT)
Date: Tue, 15 Nov 2022 21:51:54 -0800	[thread overview]
Message-ID: <CAH+w=7aRMufyzB6KZMtQ2GE0ztXFQjF0RAkqU2fhx8zxKpGhFA@mail.gmail.com> (raw)
In-Reply-To: <CAGdYchucse2HcYKHsA6Y9DrQ-21yTV=xLpvfJE=VWHbAX7C_nA@mail.gmail.com>

On Tue, Nov 15, 2022 at 11:19 AM Philippe Altherr
<philippe.altherr@gmail.com> wrote:
>
> Here is a patch with which all tests pass (the Zsh ones, including the new ones that the patch adds, and my tests mentioned in this thread).

Thanks.  Please don't name attached files with suffix ".patch",
".diff", ".zsh", etc., as some mail readers won't display them and
they won't be inlined by the zsh-workers list archive server.  Just
use ".txt" unless there is something in the attachment that would be
damaged if interpreted that way (hopefully that won't ever be true of
a patch).

> +++ b/Test/C03traps.ztst
> @@ -713,29 +713,48 @@ F:Must be tested with a top-level script rather than source or function
>      fi
>    }
>    fn() {
> -    setopt localoptions err_return
> +    setopt err_return
>      fn2 || true
>    }
> -  fn
> +  (fn)

Did using localoptions here break something?

Aside from that, I'd like to look at how we got here.  Way back in
workers/50873 (https://www.zsh.org/mla/workers/2022/msg01203.html) you
posted an attachment "bug.zsh" and wrote:

> The output of the script (with Zsh 5.8 on Linux and Zsh 5.8.1 on macOS) is the following:
>
>> aaa: 0
>> bbb: 1
>> ccc: 1
>
> The documentation of ERR_EXIT mentions the special case of conditional expressions. I understand that the command "false" by itself in the expression "false && true" shouldn't trigger an exit since it appears in a position where a condition is expected. However, since the expression "false && true" as a whole evaluates to a non-zero status and doesn't appear in a position where a condition is expected, I would assume that it should trigger an exit. Thus, in my opinion the script should have the following output:
>
>> aaa: 0
>
> That's obviously not the case.

I started making all my changes on the premise that "bbb: 1" was
incorrect output.  After fix-err-exit.patch is applied, the bug.zsh
script outputs

aaa: 0
bbb: 1

So my question is, was the whole premise of the thread that started
there, incorrect?  Because we come to workers/50897 (which
fix-err-exit.patch reverses) where I made this comment:

> There is the question of why ignoring a false status at the end of a
> complex command has so far been considered correct for ERR_EXIT,
> according to C03.  This is a disagreement with e.g. bash.

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?

Somewhere along the line we pivoted from "errexit isn't exiting in
case X" to "errexit shouldn't exit in case Y" and (given also
Lawrence's remarks RE source and eval) I'm not sure we've yet resolved
that any of the approaches to Y are satisfactory for X.

> I have no clue how you obtain the change numbers (like 50929 and 50928)

Those are zsh-workers article numbers from the X-Seq header in each
message in the archives.


  parent reply	other threads:[~2022-11-16  5:52 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 [this message]
2022-11-16  7:56                 ` Philippe Altherr
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='CAH+w=7aRMufyzB6KZMtQ2GE0ztXFQjF0RAkqU2fhx8zxKpGhFA@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=philippe.altherr@gmail.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).