bug-bash
[Top][All Lists]
Advanced

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

Re: Doc of "set -e" should mention non-locality


From: Eric Blake
Subject: Re: Doc of "set -e" should mention non-locality
Date: Wed, 04 Jul 2012 10:47:11 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/04/2012 09:37 AM, Rainer Blome wrote:

> 
> * Different POSIX shell implementations are free to behave
> differently, because the behavior is not specified exactly.

Actually, that's where you are wrong.  POSIX _does_ specify bash's
current behavior (in fact, bash changed behavior to match POSIX)

> http://pubs.opengroup.org/onlinepubs/009695399/utilities/set.html

http://austingroupbugs.net/view.php?id=52

which even includes this example:

    Application writers should avoid relying on set -e within
    functions. For example, in the following script:

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

    the -e setting is ignored within the function body (because the
    function is a command in an AND-OR list other than the last).
    Therefore if some_server fails, the function carries on to
    echo "server started successfully", and the exit status of the
    function is zero (which means "server failed" is not output).


> * Some shell implementations *do* behave differently from Bash
> in this regard. At least on AIX, ksh and sh do so.

Only because they haven't been patched to obey POSIX yet.

> 
> * The average shell programmer probably seldomly encounters
> the difference, because it rarely matters.

Actually, the average shell programmer should avoid 'set -e', because of
its historical warts and non-intuitive behavior.

-- 
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]