First off, I had earlier written this:
Now, the behavior you describe is required by the standard
Further checking shows that I was incorrect: if compliance to the
SUSv3 XSI extension is claimed, then the 'test' utility must return
true for this:
[ -n = -n -o -n = -e ]
The reference is this:
http://www.opengroup.org/onlinepubs/000095399/utilities/test.html
(You may have to fill in a form to actually get access to that.)
Of course, if XSI compliance is not claimed, then the base spec simply
says this:
>4 arguments:
The results are unspecified.
I'll note that the XSI portion of that text has been subject to
discussion on the austin-group mailing list, as it is known to be
ambiguous in some cases and to conflict with existing implementations.
There was a thread back in Jan 2006, from which I'll point people at
David Korn's final comment in the thread:
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=9010
On 12/5/06, Uwe Dippel <[EMAIL PROTECTED]> wrote:
...
2. (as I wrote) syntax can not be dependent on the value of a variable.
This is false of the 'test' utility, as it is defined to operate of
the values of its arguments, irrespective of where they came from.
For example:
[ "$x" foo ]
If x is '!', that's a negated test of whether 'foo' is a null string.
If x is '-f', that's a unary test of whether 'foo' is a regular file.
If you don't put $x in double quotes, there are many other
possibilities created by word-splitting:
if x is empty, it would be a test of whether 'foo' is a null string.
if x is 'foo =', it would be a binary test of whether 'foo' is the
same as 'foo'.
To go back to your original case:
[ "$demo" = "-n" -o "$demo" = "-e" ]
If demo is '!', then that is required to be a syntax error, as '!' has
higher precedence than -o under the XSI extension. You may wish
otherwise, but wishing so won't change the standard.
Note that your claim *is* true of the ksh "[[" builtin syntax.
...
Overall, (for those loving to read the man pages), this behaviour violates
the precedence for binary operators:
(listed and grouped in increasing order of precedence):
Binary operators:
,
= *= /= %= += -= <<= >>= &= ^= |=
...
<sigh>
You're quoting from the "Arithmetic expressions" expressions section,
which starts by saying:
Integer arithmetic expressions can be used with the let command, inside
$((..)) expressions, inside array references (e.g. name[expr]), as numer-
ic arguments to the test command, and as the value of an assignment to an
integer parameter.
I.e., it does *not* apply to the overall 'test' syntax. For that you
have to read further down, in the "Command execution" section where it
describes the 'test' builtin.
...
Woodchuck: Thanks for the confirmation of tar being frontend to pax. Then,
what is the good reason that the frontend kind of suppresses the
abilities of the underlying routine ?
What ability of pax is tar suppressing? pax can't save files with
names longer than 100 characters into 'ustar' or 'tar' format archives
either.
Philip Guenther
