bug-bash
[Top][All Lists]
Advanced

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

Re: [RFC] Logically composable variant of errexit


From: Chet Ramey
Subject: Re: [RFC] Logically composable variant of errexit
Date: Mon, 13 Oct 2014 09:40:23 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 10/10/14, 5:26 AM, Andreas Grünbacher wrote:
> 2014-10-10 3:29 GMT+02:00 Chet Ramey <chet.ramey@case.edu>:
>> What does logically composable mean in this context?
> 
> I would like the hypothetical errfail option to:
> 
>  * Behave like errexit at the top level (outside of functions).
> 
>  * Be inherited by functions,  subshells, and command substitution.
> 
>  * Inside functions, it should trigger like errexit would outside of
>    functions, no matter how the function is called.
>    It should return instead of exiting, though.

So you want executing shell functions -- and only executing functions --
to change the entire scope of errexit.  For example, you want functions to
return on an error, presumably with a non-zero return status.  However,
this is not compatible with your first point, which says that at the top
level, it would behave like errexit.  Since functions are simple commands,
a function returning a non-zero status would ordinarily cause the `top
level' to behave as if any other simple command failed.

> 
> With errexit, you get vastly different results from functions depending
> on how the functions are called, for example,

Sure, because functions are simple commands.  They are subject to the same
conditions as any other simple command.

> 
>    foo() {
>       echo "foo: top"
>       false
>       echo "foo: bottom"
>    }
> 
>    set -o errexit
> 
>    # bottom of foo reached:
>     if foo; then
>       echo "success"  # reached
>    fi
> 
>    # bottom of foo not reached:
>    foo
> 
> With errfail, "foo:bottom" and "success" would not be reached.
> 
> Command substitutions would continue to behave as basic commands
> do with respect to control flow: inside functions, a failure would cause
> the function to return; outside of functions, the script would exit.

Hmm...but command substitutions are not themselves commands: they are a
word expansion.  The fact that an assignment statement returns the status
of a command substitution in the absence of a command is a very special
case.  Given that special case, though, there is already a way to do
what you want, unless you want

some-command with some $(arguments) here

to exit the shell if $(arguments) ends up returning a non-zero status.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

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