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

[Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx>]

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.


> 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).


> Ignore what POSIX specifies for a moment. Is there any situation
> where 
> the behaviour you are asking for is what someone who writes 'set -e' 
> would want?

I haven't asked for it ;-) ... merely pointed out that it might
contradict POSIX.

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.


>  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 ).

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.


Cheers,
Chris.