Bug in ksh // Improvement for tar ?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in ksh // Improvement for tar ?

Uwe Dippel
2 humble suggestions to make my server OS of choice even better.

I seem to have found a bug in ksh:
Here is a sample that doesn't behave as I'd expect it to.

# demo=""
#  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> echo bar
> fi
# demo="-n"
#  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> echo bar
> fi
ksh: [: -n: unexpected operator/operand

IMHO, I'd consider it a bug, since the correctness of syntax must
not change with the value of the variable.
AFAIK, this syntax is considered correct generally; if not, please
advise me.


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.

Thanks for pondering about these two !

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Daniel Brosemer
On Tue, Dec 05, 2006 at 12:32:38PM +0800, Uwe Dippel wrote:

> 2 humble suggestions to make my server OS of choice even better.
>
> I seem to have found a bug in ksh:
> Here is a sample that doesn't behave as I'd expect it to.
>
> # demo=""
> #  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> > echo bar
> > fi
> # demo="-n"
> #  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> > echo bar
> > fi
> ksh: [: -n: unexpected operator/operand
>
> IMHO, I'd consider it a bug, since the correctness of syntax must
> not change with the value of the variable.
> AFAIK, this syntax is considered correct generally; if not, please
> advise me.

Take a look at the way /etc/rc does stuff like this:

odin@jangofett:ttyp1[~]$ if [ x"$demo" == x"-n" -o x"$demo" == x"-e" ]; then
> echo bar
> fi
bar

-Dan

--
"Burnished gallows set with red
 Caress the fevered, empty mind
 Of man who hangs bloodied and blind
 To reach for wisdom, not for bread."  -- Deoridhe Grimsdaughter

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Luke Bakken
In reply to this post by Uwe Dippel
> # demo=""
> #  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> > echo bar
> > fi
> # demo="-n"
> #  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> > echo bar
> > fi
> ksh: [: -n: unexpected operator/operand

/home/lukeb
$ demo='-n'
/home/lukeb
$ if [[ $demo == '-n' || $demo == '-e' ]]; then print YUP; fi
YUP
/home/lukeb
$

Single-bracket tests in ksh are old-school.

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Woodchuck-2
In reply to this post by Uwe Dippel
On Tue, 5 Dec 2006, Uwe Dippel wrote:

> 2 humble suggestions to make my server OS of choice even better.
>
> I seem to have found a bug in ksh:
> Here is a sample that doesn't behave as I'd expect it to.
>
> # demo=""
> #  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> > echo bar
> > fi
> # demo="-n"
> #  if [ "$demo" == "-n" -o "$demo" == "-e" ]; then
> > echo bar
> > fi
> ksh: [: -n: unexpected operator/operand
>
> IMHO, I'd consider it a bug, since the correctness of syntax must
> not change with the value of the variable.

It's probably more of a feature.  Probably the correct name for
it is a "wart".  The nature of name expansion in ksh, and the
syntax of the [ and other things is such that demo="" should
correctly expand to <nothing>, but the syntax of [ wants
<something> before a ==.  So in this sense, it is not a bug.
It's a disappointment, maybe.

The idiom used when a null value of "demo" matters is:

# demo=""
# if [ X"demo" == X"-n" -o X"demo" == X"-e" ]; then
> echo bar
> fi

You'll see this throughout scripts in OpenBSD, see /etc/rc for examples

> AFAIK, this syntax is considered correct generally; if not, please
> advise me.

If you mean "generally in the world of Bourne and Korn shells", then
no, it's not correct.  If you mean "generally when considering language
design" then I agree.  It all hinges around the nature of name
expansion in ksh/sh, i.e. the way sh parses a command line, which is
in various passes.  The man page for ksh will provide insight.

Dave

> 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

The system tar is a frontend to pax.  I don't know about gtar.

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Tonnerre LOMBARD-3
In reply to this post by Daniel Brosemer
Salut,

On Mon, Dec 04, 2006 at 11:45:46PM -0501, Dan Brosemer wrote:
> Take a look at the way /etc/rc does stuff like this:
>
> odin@jangofett:ttyp1[~]$ if [ x"$demo" == x"-n" -o x"$demo" == x"-e" ];
then
> > echo bar
> > fi
> bar

Sure, but this is a workaround. It is a bug that ought to be fixed. (Even
though it is admittedly a very old bug and a lot of people are using the
workaround.)

                                Tonnerre

[demime 1.01d removed an attachment of type application/pgp-signature]

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Philip Guenther-2
In reply to this post by Uwe Dippel
On 12/4/06, Uwe Dippel <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Uwe Dippel
In reply to this post by Uwe Dippel
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

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Woodchuck-2
On Wed, 6 Dec 2006, Uwe Dippel wrote:

> 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

I suspect it is to maintain compatibility with the most ancient
tars.  There are a lot of ancient archives sitting around on 12"
9- and [gasp] 7-track tape, punch cards, etc, that would be lost
forever if tar changed.  Tar, as an archive program, should be
always backward-compatible.  Nothing is as frustrating as a write-only
tape.

Sometimes we forget that this system is now ~30 years old, which
is really ancient for software, so it will accumulate a few warts
and false teeth with time.

For example -- the system call "creat(2)" has five letters because
of a limitation of an early compiler.  Should we change it to
"LetsMakeANewFile(2)"?

You can  use a tool daily, and it does its job, but lacks a feature
that the similar tool in a neighboring village has -- Still you'll
never really want that feaure, you'll never think of it -- I think
this comes into play, too.  But I cut my unix teeth on SysV, so
sometimes I wonder what happened to a SysV switch or feature.

Dave
--
  "Confound these wretched rodents! For every one I fling away,
               a dozen more vex me!" -- Doctor Doom

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Philip Guenther-2
In reply to this post by Uwe Dippel
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Uwe Dippel
On Wed, 06 Dec 2006 00:40:15 -0700, Philip Guenther wrote:

> 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 ]

and ? Does it ?
# if [ -n = -n -o -n = -e ]; then
> echo bar
> fi
ksh: [: -n: unexpected operator/operand

No, not.

> says this:
>     >4 arguments:
>         The results are unspecified.

Results are unspecified, or syntax may be wrong or right. Do as you like
...

>  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

Oh, thanks for an enlightening read, really.

And what is the second last sentence in his message ?

> As a result, the only way to get a usable test was to just use the
> number of arguments as a guide.  This way would allow most of existing
> scripts to be portable,

Does it ? No, not.


>> 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.

Which is where *I* need to correct myself. I remembered a Fine Proposal on
this same list to use pax -x cpio for long filenames. But maybe this also
doesn't work ? If it does, however, would I mind another option to tar
for those with Woodchuck's old archives; like tar -a (for antique) using
the old tar format and for the rest the frontend for pax with '-x cpio' ?
I even guess pretty much, that for -t or -x or whatsoever, the program can
understand the archive format.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Otto Moerbeek
In reply to this post by Uwe Dippel
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

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Otto Moerbeek
In reply to this post by Uwe Dippel
On Wed, 6 Dec 2006, Uwe Dippel wrote:

> 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 ?

tar is not a "frontend" to pax. Thesey share the same code, and are in
fact the same executable. The pax format is different from the ustar
format.

The ustar format is defined by POSIX and does not allow for filename
larger than 100 chars or path names larger than 255 chars.

GNU choose to provide an extension, at the cost of reduced interoperability.

I use dump and restore for backup, they were made for that and have
the nice feature of being able to do incremental backups.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Philip Guenther-2
In reply to this post by Uwe Dippel
On 12/6/06, Uwe Dippel <[hidden email]> wrote:
> On Wed, 06 Dec 2006 00:40:15 -0700, Philip Guenther wrote:
...

>>https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=9010
>
> Oh, thanks for an enlightening read, really.
>
> And what is the second last sentence in his message ?
>
> > As a result, the only way to get a usable test was to just use the
> > number of arguments as a guide.  This way would allow most of existing
> > scripts to be portable,
>
> Does it ? No, not.

Nice quote out of context there.  I especially like how you cut off
the end of his sentence, where he made clear how the non-portable
usage of -o, -a, and parens can be made portable *and* robust.

Or do you disagree with his judgement that
1) the addition of -o and -a had damaged scripts that didn't use them,
2) -o and -a were not implemented consistently at the time POSIX was
written, and
3) scripts should use one of the robust, consistent, and portable alternatives?

If so, well, I hope you enjoy that universe you live in.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Uwe Dippel
In reply to this post by Otto Moerbeek
On Wed, 06 Dec 2006 10:11:34 +0100, Otto Moerbeek wrote:

> tar is not a "frontend" to pax. Thesey share the same code, and are in
> fact the same executable. The pax format is different from the ustar
> format.
>
> The ustar format is defined by POSIX and does not allow for filename
> larger than 100 chars or path names larger than 255 chars.
>
> GNU choose to provide an extension, at the cost of reduced interoperability.

Thanks, Otto, for a clear technical explanation. (All my statements were
taken from the archive; mistakenly it seems.)
 
> I use dump and restore for backup, they were made for that and have the
> nice feature of being able to do incremental backups.

I am a big fan of dump/restore. Sometimes, it simply does not feel 'the
right tool'.
And sometimes there are archives coming from gtar. And I can't tell my
hundreds of users how crappy MS Office is (actually, I do ! But it doesn't
help very much).
Any chance to add '-g' as
"create / read an archive in gtar format. Discouraged, though ?"

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Uwe Dippel
In reply to this post by Otto Moerbeek
On Wed, 06 Dec 2006 10:03:11 +0100, Otto Moerbeek wrote:

>> # 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.

> These are all borderline cases. Follow recommended shell programming
> practises to avoid these.

Portability of *existing* software ? These examples are handled properly
(bash-bash) by "just another" shell. I guess, counting arguments is a
good helper, though I haven't looked into the code.

> This is the list of precedence for arithmetic expressions, which are not
> the same as the expressions handled by [ .. ] .

This is what I understand. Where do I find the precedences for relational
operators ? If they are different, by the way. What we see here, is that
OR has a higher precedence than ==. Life is full of surprises, though.

If someone shows that the behaviour of bash in *one of these examples*
clearly violates basic programming and shell practice, I'll shut up
immediately. Okay I shut up in any case w.r.t. this thread.
Thanks to anyone who tried to help out with their respective knowledge !

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Hannah Schroeter
In reply to this post by Uwe Dippel
Hello!

On Wed, Dec 06, 2006 at 10:17:11PM +0800, Uwe Dippel wrote:
>[...]

>And sometimes there are archives coming from gtar. And I can't tell my
>hundreds of users how crappy MS Office is (actually, I do ! But it doesn't
>help very much).
>Any chance to add '-g' as
>"create / read an archive in gtar format. Discouraged, though ?"

Why?

It's so simple to type
pkg_add -i gtar

>Uwe

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Christian Weisgerber
In reply to this post by Otto Moerbeek
Otto Moerbeek <[hidden email]> wrote:

> The ustar format is defined by POSIX and does not allow for filename
> larger than 100 chars or path names larger than 255 chars.
>
> GNU choose to provide an extension, at the cost of reduced interoperability.

BTW, GNU tar changed the extension back in ~1992.  The old scheme
has still been supported for reading ever since, but somebody
recently discovered a path traversal vulnerability there and in
response any support for the old scheme will be removed from gtar
1.16.1.  (It's already disabled in our gtar-1.16p0 package.)

While I don't expect many people to still need to access archives
that are that old and use the extension, a few will probably be
bitten by this.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Uwe Dippel
In reply to this post by Philip Guenther-2
On Wed, 06 Dec 2006 03:15:44 -0700, Philip Guenther wrote:

> If so, well, I hope you enjoy that universe you live in.

Since someone informed me that ksh on Solaris processes the discussed
expressions properly, I might feel tempted to evaluate David's opinion
on the behaviour he'd prefer.
Maybe your universe would shrink ?

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Philip Guenther-2
On 12/9/06, Uwe Dippel <[hidden email]> wrote:
> On Wed, 06 Dec 2006 03:15:44 -0700, Philip Guenther wrote:
> > If so, well, I hope you enjoy that universe you live in.
>
> Since someone informed me that ksh on Solaris processes the discussed
> expressions properly, I might feel tempted to evaluate David's opinion
> on the behaviour he'd prefer.
> Maybe your universe would shrink ?

There appears to be a bug in your mail client that results in your
replies taking other peoples' statements out of context.  If you fixed
that bug then you wouldn't have to spend so much energy fighting
strawmen.

Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: Bug in ksh // Improvement for tar ?

Igor Sobrado
In reply to this post by Uwe Dippel
I am not a member of this mailing list, so I will copy and paste
the comment of Philip Guenther here:

"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."

Agreed, GNU tar has some serious problems managing long filenames
(and not so long filenames, a short filename on a complex directory
hierarchy is all required to break it.)

I worked on a fix to gtar in 1998 (we called it "adjusting gtar to the
POSIX 1003.1 (ustar) standard).  There were very annoying problems
sharing data between PCs with Linux, our HP-UX servers and Solaris
workstations at that time.  At that time, it was only required
extracting the contents of some Solaris patches on a Linux machine
to see what this problem means.

Sadly, this patch is only applied to gtar releases when the maintainer
of this application is Frangois Pinard.  In this case, gtar is
compatible with pax(1) on most operating systems.  I am certainly
against a patch that breaks the excellent compatibility between pax(1),
cpio(1) and tar(1) on OpenBSD and these tools on other platforms.
If gtar is incompatible... well... it is the decision of the maintainers
of gtar, the patch is available.

On the other hand, this problem happens when the filenames (including
both the dirname and basename) are larger than one hundred characters.
You mention a different issue, filenames larger than 255 characters.
I am sure there is something that can be done to avoid so large filenames,
like educating Windows users to choose better filenames.

Cheers,
Igor.