On 12/4/06, Uwe Dippel <[EMAIL PROTECTED]> wrote:
I seem to have found a bug in ksh:
Here is a sample that doesn't behave as I'd expect it to.
...
First off, the string equality operator in 'test' is "=", not "==".
Yes, openbsd accepts "==", but other systems will yell at you if you
try that.
Now, the behavior you describe is required by the standard. You have
the following choices for getting the behavior you want:
1) put something fixed before the items on each side of the '=' and '!=' tests:
if [ X"$demo" = X"-n" -o X"$demo" = X"-e" ]; then
2) use the ksh builtin '[[', which handles the quoting for you too and
offers correct
precedence in complicated situations:
if [[ $demo = "-n" || $demo = "-e" ]]; then
3) use the POSIX rules for how 'test' behaves with exactly three
arguments to solve it:
if [ "$demo" = -n ] || [ "$demo" = -e ]; then
4) combine (1) and (3) to get the maximally portable version:
if [ X"$demo" = X"-n" ] || [ X"$demo" = X"-e" ]; then
IMHO, I'd consider it a bug, since the correctness of syntax must
not change with the value of the variable.
To quote the 'test' manpage:
GRAMMAR AMBIGUITY
The test grammar is inherently ambiguous. In order to assure a degree of
consistency, the cases described in IEEE Std 1003.2 (``POSIX.2'') section
D11.2/4.62.4 are evaluated consistently according to the rules specified
in the standards document. All other cases are subject to the ambiguity
in the command semantics.
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.
The 'cpio' format for pax (selected using "-x cpio") handles long file
names in a portable way, as opposed to GNU tar's non-portable
extension for handling file names longer than 100 bytes.
Philip Guenther
