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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux