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.
