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

[John Kearney]

Am 13.01.2013 00:04, schrieb Chet Ramey:
> On 1/12/13 10:07 AM, John Kearney wrote:
>
>> regarding -e it mainly has a bad name because there is no good guide how
>> to program with it.
>> so for example this causes stress
>> [ ! -d ${dirname} ] && mkdir ${dirname}
>> because if the dir exists it will exit the scripts :)
> I'm not sure this is what you wanted to say.  When -e is set, that code
> will not cause an error exit if ${dirname} exists and is a directory.  Run
> this script in the bash source directory and see what happens:
>
> set -e
> [ ! -d builtins ] && mkdir builtins
> echo after
>
>
> Chet
:)
its a little more complex, truthfully I make rules how I should do stuff
and then just follow them.

in this case you actually need to put the code in a function, then its
actually the function return not the command itself that causes the
exit. At least I think thats what happens, truthfully sometimes even
with the caller trace it can be hard to tell what is actually going on.
i.e.

set -o errexit
test_func() {
    [ ! -d test ] && echo test2
}

echo test3
test_func
echo test4

now so long as test doesn't exist in the cwd it should errexit.
at least it did for me just now.

Like I say the only reason I don't like errexit is it doesn't say why it
exited, so I use the ERR trap. Which is great.


Just to clarify I'm not complaining just saying why I think ppl have bad
experiences with errexit.

having said that it might be nice to get an optional backtrace on
errors. I do this myself but it might help others if it was natively
supported.

John