bug-gnulib
[Top][All Lists]
Advanced

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

Re: FYI: do-release-commit-and-tag: fix typo


From: Eric Blake
Subject: Re: FYI: do-release-commit-and-tag: fix typo
Date: Thu, 05 Jul 2012 09:28:02 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/05/2012 09:16 AM, Akim Demaille wrote:
> 
> Le 5 juil. 2012 à 16:53, Jim Meyering a écrit :
> 
>> This script doesn't use set -e.
>> I'd say that having to limit such use of "&&" is a good reason
>> not to use "set -e".
> 
> In my experience, not setting set -e is asking for troubles.
> I have been bitten way too often because of failures that go
> unnoticed, and the script just continues.

In my experience, 'set -e' is worthless in any shell scripting mixed
with functions.  Test yourself - what does this output?

        set -e
        start() {
           false
           echo started successfully
        }
        start || echo >&2 failed

Believe it or not, POSIX requires it to output 'started successfully'
(why? see http://austingroupbugs.net/view.php?id=52).  Furthermore, not
all /bin/sh obey POSIX, so you aren't even guaranteed that behavior
across platforms.

'set -e' can be useful in a strictly-controlled style of shell coding,
but the POSIX rules on how it behaves are quite non-intuitive and cause
more confusion than bugs that it would otherwise prevent by early exit
on error; and my opinion is that while all errors should be detected,
using 'set -e' as the crutch for the detection mechanism is bound to
cause careless programming that is harder to fix than coding correctly
in the first place.

-- 
Eric Blake   address@hidden    +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]