On Wed, 6 Dec 2006, Uwe Dippel wrote:
> 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:
Welcome to the world of string based processing. ksh implements '['
the same as it used to be: an external command. This means that quotes
get stripped and so on. This is to remain compatible with older shells.
> # 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
Yes it is strange these are not accepted while the expression below is.
> though there is no ambiguity in the left part. Finally, it *does* this
> properly:
> # if [ "-n" == "foo" ]; then
> > echo bar
> > fi
I think this is parsed as:
(-n empty string) == foo
Try
if [ -n == ]; then echo bar; fi
These are all borderline cases. Follow recommended shell programming
practises to avoid these.
> #
> 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:
>
> ,
> = *= /= %= += -= <<= >>= &= ^= |=
> ||
> &&
> |
> ^
> &
> == !=
This is the list of precedence for arithmetic expressions, which are
not the same as the expressions handled by [ .. ] .
>
> 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 ?
I'll reply to this in a separate thread.
-Otto
