Thanks for all the answers !
My concern was not the empty demo:
> # demo=""
> # if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
>> echo bar
>> fi
> #
which behaves logically (demo is not equal to neither -n nor -e; and so
bar is not printed).
My concern is more about this:
> # demo="-n"
> # if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
>> echo bar
>> fi
> ksh: [: -n: unexpected operator/operand
since
1. the expression is found 'valid' on any *ksh* tutorial or book
(though the [[ || ]] is preferred);
2. (as I wrote) syntax can not be dependent on the value of a variable.
Ambiguity of an expression does not include invalidating syntax by
another value.
3. (Luke and Philip) I *am* talking about portability; the
whole matter came up when I tried to run rkhunter on OpenBSD (I know, not
needed !). But that software has around 5000 lines and plenty of tests,
and it runs properly on - don't bash me - bash. No, I don't want bash. I
do like a consistent behaviour of (pd)ksh. As far as I understand, the
problem stems from a non-sensical treatment of the expression. If you
write
# demo=foo
# if [ "$demo" == "foo" -o "$demo" == "-e" ]; then
> echo bar
> fi
bar
That's fine. Obviously, ksh knows to handle the ambiguity properly ! Now:
# demo="-n"
# if [ "$demo" == "foo" -o "$demo" == "-e" ]; then
> echo bar
> fi
ksh: [: foo: unexpected operator/operand
This is what I still consider a bug, having read all answers.
A line of source code can't become invalid
syntax by a 'wrong' variable. The problem seems - as mentioned above - the
wrong interpretation of the function of string "foo"; by somehow
misinterpreting the "$demo" as -n:
# if [ -n == "foo" -o "$demo" == "-e" ]; then
> echo bar
> fi
ksh: [: foo: unexpected operator/operand It should properly do this,
though:
# if [ "-n" == "foo" -o "$demo" == "-e" ]; then
> echo bar
> fi
ksh: [: foo: unexpected operator/operand but still, it doesn't. Even
though there is no ambiguity in the left part. Finally, it *does* this
properly:
# if [ "-n" == "foo" ]; then
> echo bar
> fi
#
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:
,
= *= /= %= += -= <<= >>= &= ^= |=
||
&&
|
^
&
== !=
man ksh also states:
expr -o expr Logical OR.
> Secondly, I still need to resort to gtar for the backup of my users'
> home directories (you know those silly long filenames in WORD). I
> understand it is just a frontend to pax ? If it could process file names
> with a length of 255, I'd be happy, I think.
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 ?
Thanks,
Uwe
