Re: builtin test command file existence fails with negation

[Pierre Gaston]

On Tue, Jul 21, 2009 at 8:42 PM, Lynn Kerby <lfk@kerbit.net> wrote:

>
> Thanks, I hadn't read the Open Group test command doc.  However, I find the
> doc inconsistent on this matter when read in its entirety.
>
> For starters, POSIX doesn't allow for the use of '-a' as a unary operator
> (according to the RATIONALE section this is because mere humans will be
> confused and should use '-e' instead). In that context, the parsing of 3
> arguments to test could proceed on the assumption that any '-a' option in
> the middle would be an attempt to perform a binary operation.  The GNU bash
> and test command do support the historical '-a' unary operator usage as a
> unary operator, so its hard to justify this behavior as POSIX conformant
> IMO.  It might be, but it is pretty clearly wrong.


It justifies that bash does the posixly correct thing in returning always
true for "test ! -a foo"


> So if I'm reading that corrrectly, the '!' operator is supposed to have a
> higher precedence than the '-a' operator in complex expressions.  Simply
> adding a "-a 1" to the expression (resulting in " ! -a file -a 1") causes a
> different parsing behavior.  It seems that the 3 argument processing rules
> for the test command violate this by having the negation test ordered after
> binary primaries.  The rules for 2 and 4 argument parsing clearly handle
> negation first.
>
> I still consider this a bug, since this is caused by an ambiguity (at some
> level) in a non-POSIX defined operator.  Blaming it on a POSIX defined
> argument processing rule doesn't really apply here.  Whatever the
> disposition, I'm going to be modifying this bunch of scripts (inherited) to
> use the '-e' unary operator for existence tests.
>


This "inversion of priorities" with 3 arguments is documented in man bash.

(note that posix doesn't even define what test should do with more than 4
arguments, I find better to not use -a at all and to  chain several test
command with && or ||, I also
find this more readable, some people prefer the ksh/bash [[  keyword which
allows you to use && rather than -a)