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
