On 11/22/2011 02:02 AM, Stefano Lattarini wrote: >>> test a = "$b" >>> >>> is just as likely to trigger improper evaluation in buggy test(1) >>> implementations as: >>> >>> test "$b" = a >> >> :-o For real? On non-museum pieces?
Okay, you've convinced me otherwise. It looks like even buggy versions
of test(1) at least have the decency to recognize "non-op" "="
"arbitrary" as always being a string comparison, even if "arbitrary"
looks like an operator (I tried "!", "=", "(", ")", "-a", and so on).
It is only when the first argument looks like an operator that the
parser gets confused on what the remaining two arguments should be.
> And in fact the autconf manual says:
>
> Similarly, Posix says that both `test "string1" = "string2"' and
> `test "string1" != "string2"' work for any pairs of strings, but
> in practice this is not true for troublesome strings that look
> like operators or parentheses, or that begin with `-'.
>
> (Text that should be probably be expandend to show some examples,
> *and* to report the exact names and versions of the affected
> shells).
Yes, the autoconf manual could be improved, based on the results of this
thread.
>
>> I tested a bunch of /bin/sh, bash, ksh and zsh versions that I have
>> easy access to, and for all of them, the only way to upset test with
>> leading hypens the first argument.
>>
> I couldn't do this either (for leading hypens, that is); but see the
> slighlty more elaborated issues presented above.
I can demonstrate a problem with leading hyphen, on Solaris 10 at least:
$ touch =; /bin/sh -c 'test -f ='; echo $?
/bin/sh: test: argument expected
1
>>
>> I'll postpone pushing this patch until we get to the bottom of the
>> issue though.
I withdraw my objection to the libtool patch. It might not be a common
idiom to list the constant first, but who knows? maybe you've started a
new trend.
--
Eric Blake ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
