bug-bash
[Top][All Lists]
Advanced

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

Re: why does errexit exist in its current utterly useless form?


From: Eric Blake
Subject: Re: why does errexit exist in its current utterly useless form?
Date: Fri, 14 Dec 2012 16:23:41 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/14/2012 04:07 PM, address@hidden wrote:
> I recently worked on a project involving many bash scripts, and I've been 
> trying to use errexit to stop various parts of a script as soon as anything 
> returns a non-0 return code. As it turns out, this is an utterly useless 
> endeavour. In asking this question on this forum, I hope somebody out there 
> can help me, who understands bash, POSIX, and why decisions were made to 
> arrive at the current situation.

Short answer: historical compatibility.  'set -e' has been specified to
behave the way it did 30 years ago in one reference implementation, and
while you can argue till you are blue in the face that the reference
implementation is not intuitive, you have to at least appreciate that
having a standard means you are likely to get the same (non-intuitive)
behavior among several competing shell implementations that all strive
to conform to POSIX.

Personal recommendation: 'set -e' is probably not worth your effort,
especially not if you use shell functions.

> My initial gripe about errexit (and its man page description) is that the 
> following doesn't behave as a newbie would expect it to:
> 
> set -e
> f() {
>   false
>   echo "NO!!"
> }
> f || { echo "f failed" >&2; exit 1; }

Indeed, the correct behavior mandated by POSIX (namely, that 'set -e' is
completely ignored for the duration of the entire body of f(), because f
was invoked in a context that ignores 'set -e') is not intuitive.  But
it is standardized, so we have to live with it.

> 
> Question 4: Back to the original f, why did bash (or even POSIX) decide to 
> protect the "false" statement?

Because once you are in a context that ignores 'set -e', the historical
behavior is that there is no further way to turn it back on, for that
entire body of code in the ignored context.  That's how it was done 30
years ago, before shell functions were really thought about, and we are
stuck with that poor design decision.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]