On Wed, Aug 23, 2017 at 04:24:55PM +0200, Dethrophes wrote:
Which I always understood as the correct way of doing this in the
first place...
It's not as good as multiple test commands: test -f file && test -x
file.
There's no ambiguity and you get short-circuiting.
Only if you are using the test built-in, otherwise the latter means 2
spawns/forks however the shell in question calls the test exec.
The comparison was against "test -f file -a -x file" which is deprecated.
The use of "-a" as a logical AND is not mandated by POSIX except in
"obsolescent XSI" mode.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
http://pubs.opengroup.org/onlinepubs/9699919799/help/codes.html#OB%20XSI
So if you're using test ... -a ... then you're almost certainly relying
on test being bash's builtin version. And since this is bug-bash, we
generally assume you are using bash.
There is also test(1) in GNU coreutils, which currently still supports
the binary -a, but the coreutils 8.26 man page says "NOTE: Binary -a
and -o are inherently ambiguous. Use 'test EXPR1 && test EXPR2' or
'test EXPR1 || test EXPR2' instead."
But, writing a script that relies on test being the one provided by
GNU coreutils (or any other version which implements the obsolescent
XSI deprecated feature set) is also extremely silly.