On 09/10/2015 06:39 PM, Andrey Repin wrote:

>>>> [ ... -a ... ] is not portable; there are some inherently ambiguous
>>>> situations that it cannot handle. POSIX recommends that you spell it [
>>>> ... ] && [ ... ] instead.
>>>

> 
> If a script author did not quote the indirect references, it is their fault,

No, even with proper quoting, the use of -a and -o creates ambiguous
situations.  For example, a naive read would claim that

test "$var1" -a "$var2"

sets $? to 0 only if both "$var1" and "$var2" are non-empty.  But
according to the POSIX rules, if $var1 is '!' and $var2 is '', then this
MUST be treated as the negation of the unary operator '-a "$var2"', if
the shell has a unary -a (bash does, dash does not).  And in bash's
case, '-a ""' is false (the empty string never exists as a file), so the
negation is true, and you have a case where the -a version returned 0 in
spite of one of the inputs being empty.

To get what you naively wanted, you HAVE to use:

test "$var1" $$ test "$var2"

Another tricky one is

test ! "$var1" -a "$var2"

because some people naively assume it matches C precedence rules to mean:

test \( ! "$var1" \) -a "$var2"

while POSIX claims it means:

test ! \( "$var1" -a "$var2" \)

except that you can't use () to force the precedence, because POSIX says
that 5 or more arguments to test causes unspecified results.  But it is
unambiguous what you meant when you write:

test ! "$var1" && test "$var2"

or

! { test "$var1" && test "$var2"; }


> not an inherent "portability issue".

It is inherently ambiguous to use -a or -o, so using them at all on
unknown user input is risky.  Furthermore, POSIX has explicitly marked
-a and -o to be optional (only XSI systems have to have them) and
obsolete (they may be withdrawn in a future revision of POSIX, because
of their ambiguity problems).  Therefore it is inherently a portability
issue (as different shells have different behaviors, and future shells
may have further different behaviors).

> I don't see, how your statement could be valid.

Then you haven't read POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

> The "[ ... ] && [ ... ]" doesn't mean the same as testing two conditions in
> one statement.

There is no semantic difference to testing in two statements, because [
is a shell builtin. It costs the same amount of work, and zero fork()s,
either way.

If you really are that opposed to using two shell statements, then
remember that we are using bash, and spell it:

[[ ... && ... ]]

rather than using -a.  At least THAT is guaranteed to work sanely,
although it is not (yet) specified by POSIX.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org