Yet another errexit bug?

Yet another errexit bug?

[Bart Schaefer]

I thought we'd squashed all of these, but:

% ! ( setopt errexit; false; print notreached )
notreached
% print $?
1

Compare bash:

$ ! ( set -e; false; echo notreached; )
$ echo $?
0

Zsh still leaking "noerrexit" into subshells, I guess?

Curiously however, bash (5.0.17):

$ ( set -e; false; echo notreached; ) && echo here
notreached
here

So bash is treating a subshell in AND/OR as different than subshell
preceded by NOT?  Zsh matches bash in the AND case, so maybe zsh's NOT
behavior is actually more consistent?

Re: Yet another errexit bug?

[Lawrence Velázquez]

On Fri, Sep 20, 2024, at 2:05 PM, Bart Schaefer wrote:
> I thought we'd squashed all of these, but:
>
> % ! ( setopt errexit; false; print notreached )
> notreached
> % print $?
> 1
>
> Compare bash:
>
> $ ! ( set -e; false; echo notreached; )
> $ echo $?
> 0
>
> Zsh still leaking "noerrexit" into subshells, I guess?
>
> Curiously however, bash (5.0.17):
>
> $ ( set -e; false; echo notreached; ) && echo here
> notreached
> here
>
> So bash is treating a subshell in AND/OR as different than subshell
> preceded by NOT?  Zsh matches bash in the AND case, so maybe zsh's NOT
> behavior is actually more consistent?

From a quick reread, it seems to me that zsh is satisfying the "!"
requirement of POSIX "set", while bash isn't:

	The -e setting shall be ignored when executing the compound
	list following the "while", "until", "if", or "elif" reserved
	word, a pipeline beginning with the "!" reserved word, or
	any command of an AND-OR list other than the last.

And these shells agree with zsh:
  - dash 0.5.12
  - ksh93u+ 2012-08-01
  - mksh R59 2020/10/31
  - OpenBSD 7.5 pdksh
  - yash 2.56.1

	% cat /tmp/foo.sh
	! (set -e; false; echo notreached)
	echo "$?"
	% bash /tmp/foo.sh
	0
	% bash --posix /tmp/foo.sh
	0
	% dash /tmp/foo.sh
	notreached
	1
	% ksh /tmp/foo.sh
	notreached
	1
	% mksh /tmp/foo.sh
	notreached
	1
	% oksh /tmp/foo.sh
	notreached
	1
	% yash /tmp/foo.sh
	notreached
	1
	% zsh /tmp/foo.sh 
	notreached
	1

-- 
vq

Re: Yet another errexit bug?

[Lawrence Velázquez]

On Fri, Sep 20, 2024, at 5:15 PM, Lawrence Velázquez wrote:
> On Fri, Sep 20, 2024, at 2:05 PM, Bart Schaefer wrote:
>> I thought we'd squashed all of these, but:
>>
>> % ! ( setopt errexit; false; print notreached )
>> notreached
>> % print $?
>> 1
>>
>> Compare bash:
>>
>> $ ! ( set -e; false; echo notreached; )
>> $ echo $?
>> 0
>>
>> Zsh still leaking "noerrexit" into subshells, I guess?
>>
>> Curiously however, bash (5.0.17):
>>
>> $ ( set -e; false; echo notreached; ) && echo here
>> notreached
>> here
>>
>> So bash is treating a subshell in AND/OR as different than subshell
>> preceded by NOT?  Zsh matches bash in the AND case, so maybe zsh's NOT
>> behavior is actually more consistent?
>
> From a quick reread, it seems to me that zsh is satisfying the "!"
> requirement of POSIX "set", while bash isn't:
>
> 	The -e setting shall be ignored when executing the compound
> 	list following the "while", "until", "if", or "elif" reserved
> 	word, a pipeline beginning with the "!" reserved word, or
> 	any command of an AND-OR list other than the last.

Looks like Chet has fixed this in the latest devel commit [*]:

	% cat /tmp/foo.sh
	! (set -e; false; echo notreached)
	printf '%s\n' "$?" "$BASH_VERSION"
	% bash /tmp/foo.sh
	0
	5.2.32(1)-release
	% ./bash /tmp/foo.sh
	notreached
	1
	5.3.0(10)-beta

[*] https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=254081c09767738833cdf161b4bc3feb1a51690a

-- 
vq