Re: set -e not ignored in AND-OR list

On 10/11/2024 16:52, Christoph Anton Mitterer wrote:
> Hey Harald.
> 
> On Sun, 2024-11-10 at 10:04 +0000, Harald van Dijk wrote:
>> I think you're right that POSIX specifies the behaviour.
> 
> Herbert still said it (I presume the ignoring of set -e) would not
> apply to command substitution subshells, though I haven't found
> anything yet, which would mandate this.

To be clear, I'm agreeing with your understanding of what POSIX says.

>> The reason why bash by default behaves contrary to what POSIX
>> specifies
>> is that what POSIX specifies is not useful. In command substitutions,
>> ignoring set -e in the way that you are asking for is even less
>> useful.
> 
> You mean now with respect to "inheriting" -e, right? Not with respect
> to ignoring -e (because there it seems to behave as POSIX says).

Yes.

Basically, my view is that the way 'set -e' is specified to work is only 
useful for the most simple basic cases. The way it is specified to work 
is not really useful for anything more complicated. The way it works 
differently in bash, in non-POSIX mode, is to make it useful in more 
cases, but still not all.

> Actually, there's IMO no case were it makes much sense to ignore set -e
> ... not even in the first command list of an if/etc. ... because if
> that e.g. calls a function, the function may depend on it exiting in a
> set -e case, and no just keep going.

I agree.

>>   Is there a real use case that would be helped by making this
>> change? If there is, I am not seeing it.
> 
> If Herbert is right and POSIX allows for this, it should IMO still
> explicitly be documented in the manpage (probably at both, set -e and
> command substitution documntation ).

Sure, that I do agree with. In dash, the effect of 'set -e' in a command 
substitution is that a command is never considered "tested", unless that 
testing happens inside the command substitution, and it would be useful 
for that to be documented.

> If POSIX would forbid it, but dash would still keep it, it should
> perhaps additionally be documented in some POSIX-incompatibilites
> section?
> 
> Reasons for changing the behaviour could be:
> - breaking software that already depend on the behaviour ;-)
> - being in line (and thus especially *portable*) with what POSIX says
>    (which is might also be used as kind of a documentation an thus
>    people could blindly assume the behaviour).
> - behaving more similar to bash (which is of course no must, but surely
>    not bad either).
> 
> 
> If it's however long standing behaviour of dash (and perhaps others),
> maybe POSIX should instead be revised.

Yes, that would be my preference. This is already something scripts 
cannot rely on, because widely used shells (bash and dash) are not in 
agreement. And I see at least mksh appears to behave the same way as dash:

   $ mksh -ec 'echo $(false; echo 123) || :'

The output is a blank line, like in dash.

Cheers,
Harald van Dijk