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
