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