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 --]
next prev parent 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).