[Top][All Lists]

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

Re: typeset -p on an empty integer variable is an error. (plus -v test w

From: John Kearney
Subject: Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
Date: Mon, 14 Jan 2013 20:57:41 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

Am 14.01.2013 20:25, schrieb Greg Wooledge:
> On Mon, Jan 14, 2013 at 08:08:53PM +0100, John Kearney wrote:
>> this should exit.
>> #!/bin/bash
>> set -e
>> f() { test -d nosuchdir && echo no dir; }
>> echo testings
>> f
>> echo survived
> OK, cool.  That gives me more ammunition to use in the war against set -e.
> ==========================================================
> imadev:~$ cat foo
> #!/bin/bash
> set -e
> test -d nosuchdir && echo no dir
> echo survived
> imadev:~$ ./foo
> survived
> ==========================================================
> imadev:~$ cat bar
> #!/bin/bash
> set -e
> f() { test -d nosuchdir && echo no dir; }
> f
> echo survived
> imadev:~$ ./bar
> imadev:~$ 
> ==========================================================
> imadev:~$ cat baz
> #!/bin/bash
> set -e
> f() { if test -d nosuchdir; then echo no dir; fi; }
> f
> echo survived
> imadev:~$ ./baz
> survived
> ==========================================================
>> All I was pointing out that its safer to use syntax
>> [] ||
>> or
>> [] && ||
> I don't even know what "safer" means any more.  As you can see in my
> code examples above, if you were expecting the "survived" line to appear,
> then you get burned if you wrap the test in a function, but only if the
> test uses the "shorthand" && instead of the "vanilla" if.
> But I'm not sure what people expect it to do.  It's hard enough just
> documenting what it ACTUALLY does.
>> you always need a || on a one liner to make sure the return value of the
>> line is a 0.
> Or stop using set -e.  No, really.  Just... fucking... stop. :-(
>> but lets say you want to do 2 things in a function you have to do
>> something like.
>> f(){
>>     mkdir "${1%/*}" ||return $?  # so the line doesn't return an error.
>>     touch "${1}"
>> }
> ... wait, so you're saying that even if you use set -e, you STILL have to
> include manual error checking?  The whole point of set -e was to allow
> lazy people to omit it, wasn't it?
> So, set -e lets you skip error checking, but you have to add error checking
> to work around the quirks of set -e.
> That's hilarious.
I have no idea why errexit exists I doubt it was for lazy people
thought. its more work to use it.
I use trap ERR not errexit, which allows me to protocol unhandled errors.

I actually find trap ERR/errexit pretty straight forward now. I don't
really get why people are so against it. Except that they seem to have
the wrong expectations for it.

|| return $?

isn't actually error checking its error propagation.

        # not last command in function
    mkdir "${1%/*}"              # exit on error.
    mkdir "${1%/*}" ||return $?  # return an error.
    mkdir "${1%/*}" ||true       # ignore error.

        # last command in function
    touch "${1}"                # return exit code

what is confusing though is

    touch "${1}"                # exit on error
    return $?

this wll not work as expected with errexit.

because the touch isn't the last command in the function, however just
removing the return should fix it.

also need to be careful of stuff like

need something more like
if x=$(false) ; then

basically any situation in which a line returns a non 0 value is
probably going to cause the exit especially in functions.

I just do it automatically now.

I guess most people aren't used to considering the line return values.

reply via email to

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