zsh-workers
 help / color / mirror / code / Atom feed
From: Philippe Altherr <philippe.altherr@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>, zsh-workers@zsh.org
Subject: Re: [PATCH] More ERR_EXIT (was Re: Tests RE behavior of ERR_EXIT)
Date: Sun, 13 Nov 2022 04:59:00 +0100	[thread overview]
Message-ID: <CAGdYchu66aYu+3yzYGtMnNcT6GcWziWe9YWNqOv5_T=JpCynRg@mail.gmail.com> (raw)
In-Reply-To: <CAGdYchsPpEMNwWFtukBS1ZzWob_hZOm8Mnnmp9Uey2T4pWs63g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4773 bytes --]

>
> My high-level understanding of exception 3 is that if an error was
> produced by a condition (note that the last command in a sub-list is NOT a
> condition but a regular command), then that error should bubble up the
> evaluation stack, without triggering any ERR_EXIT, until it gets ignored
> (for example on the left of a ";" in a sequence) or it becomes the result
> of an enclosing function or subshell.


In other words, an error produced by a condition should never trigger an
ERR_EXIT unless it becomes the result of a function or of a subshell, in
which case an ERR_EXIT should be triggered at the calling point of the
function or subshell.

I assume that command substitutions play the same role as subshells and may
turn errors from conditions into ERR_EXITs. However, I assume that they
only ever do so if their result isn't ignored. So "v=$(...)" may trigger an
ERR_EXIT but never ": $(...)". I added new tests for that and Bash does
indeed behave like that.

Below is the new set of tests .I dropped the one for always blocks and for
sequences, i.e., all the "foo?3" and "foo?4" tests because they don't
differ from the "foo?2" tests. I also reordered the tests to better group
together the ones that behave correctly.

function foo1AX() {           init;               false
>       ; }
> function foo1AY() { init; v=$(init;               false
>        ); }
> function foo1AZ() { init; : $(init;               false
>        ); }



function foo1BX() {           init;               false && true
>       ; }
> function foo1BY() { init; v=$(init;               false && true
>        ); }
> function foo1BZ() { init; : $(init;               false && true
>        ); }



function foo1CX() {           init;               false && true    ; echo
> foo >&2;  }
> function foo1CY() { init; v=$(init;               false && true    ; echo
> foo >&2); }
> function foo1CZ() { init; : $(init;               false && true    ; echo
> foo >&2); }



function foo2AX() {           init; if true; then false        ; fi
>       ; }
> function foo2AY() { init; v=$(init; if true; then false        ; fi
>        ); }
> function foo2AZ() { init; : $(init; if true; then false        ; fi
>        ); }



function foo2BX() {           init; if true; then false && true; fi
>       ; }
> function foo2BY() { init; v=$(init; if true; then false && true; fi
>        ); }
> function foo2BZ() { init; : $(init; if true; then false && true; fi
>        ); }



function foo2CX() {           init; if true; then false && true; fi; echo
> foo >&2;  }
> function foo2CY() { init; v=$(init; if true; then false && true; fi; echo
> foo >&2); }
> function foo2CZ() { init; : $(init; if true; then false && true; fi; echo
> foo >&2); }


And here are the updated results:


         Zsh 5.8.1              Zsh 5.9.0.1-dev        Bash
> 5.1.16(1)-release



foo1AX   Exit in foo*           Exit in foo*           Exit in foo*
> foo1AY   Exit in $() and foo*   Exit in $() and foo*   Exit in $() and foo*
> foo1AZ   Exit in $()            Exit in $()            Exit in $()



foo1BX   Exit in bar            Exit in bar            Exit in bar
> foo1BY   Exit in foo*           Exit in foo*           Exit in foo*
> foo1BZ   No exit                No exit                No exit



foo1CX   No exit                No exit                No exit
> foo1CY   No exit                No exit                No exit
> foo1CZ   No exit                No exit                No exit



foo2AX   Exit in foo*           Exit in foo*           Exit in foo*
> foo2AY   Exit in $() and foo*   Exit in $() and foo*   Exit in $() and foo*
> foo2AZ   Exit in $()            Exit in $()            Exit in $()



foo2BX   No exit                Exit in foo*           Exit in bar
> foo2BY   Exit in foo*           Exit in $() and foo*   Exit in foo*
> foo2BZ   No exit                Exit in $()            No exit



foo2CX   No exit                Exit in foo*           No exit
> foo2CY   No exit                Exit in $() and foo*   No exit
> foo2CZ   No exit                Exit in $()            No exit


- Bash behaves correctly for all tests (from my understanding of the POSIX
spec).
- Zsh 5.8 and 5.9 behave correctly for all "foo1??" and "foo2A?" tests.
- For all "foo2B?" and "foo2C?" tests, either Zsh 5.8 and/or Zsh 5.9 behave
incorrectly.
- Command substitutions don't seem to have any problem (of their own).
   - In other words, only test foo2BX and foo2CX matter. If they get fixed,
I expect the other ones to be fixed too.
- The problem seems to be related to how "false && true" interacts with
other constructs.
   - In Zsh 5.9 the problem seems to be that compound commands now
incorrectly trigger ERR_EXIT.
   - In Zsh 5.8 I can't pinpoint the problem, for now.

Philippe

[-- Attachment #2: Type: text/html, Size: 9673 bytes --]

  reply	other threads:[~2022-11-13  3:59 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 [this message]
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
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='CAGdYchu66aYu+3yzYGtMnNcT6GcWziWe9YWNqOv5_T=JpCynRg@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).