On Sun, 2024-11-10 at 17:06 +0000, Harald van Dijk wrote: > > 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. Yes, I've understood it that way :-) > 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. Yes. The more complicated the program gets the more "unpredictable" it seems. > > 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. The way set -e is currently documented (with "tested" vs. "untested") in the manpage is IMO already a bit strange. But your text makes it rather even more complicated O:-D What about something like: The exit status of a command +(excluding any commands within command substitutions therein) is considered to be explicitly tested if the command is used to control an if, elif or so...?! I mean AFAIU set -e is NOT ignored only for the commands IN the command substitution, but IS still ignored for the overall result of the command substitution (as part of an if, while, etc.). > > > If it's however long standing behaviour of dash (and perhaps > > others), > > maybe POSIX should instead be revised. > > Yes, that would be my preference. Another "downside" of allowing command substitutions to ignore the ignoring of set -e is however that things get even more complicated. I mean it's already crazy enough that for pipelines only the ! negated ones and for AND-OR lists only all but the last elements are affected by the set -e ignoring. Generally excluding command substitutions from all these cases would make it even more complex to understand and easy to forget while coding. Cheers, Chris.