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

[John Kearney]

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.

btw
|| return $?

isn't actually error checking its error propagation.


f(){
        # 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

f(){
    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

x=$(false)
need something more like
x=$(false||true)
 
or
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.