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.
