Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
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: [EMAIL PROTECTED]: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
Re: Bug in ksh // Improvement for tar ?
# 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.
Re: Bug in ksh // Improvement for tar ?
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 , but the syntax of [ wants 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.
Re: Bug in ksh // Improvement for tar ?
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: > > [EMAIL PROTECTED]: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]
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
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 exprLogical 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
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
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/95399/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 <[EMAIL PROTECTED]> 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: , = *= /= %= += -= <<= >>= &= ^= |= ... 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
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
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 exprLogical 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
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
On 12/6/06, Uwe Dippel <[EMAIL PROTECTED]> 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
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
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.
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
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
Re: Bug in ksh // Improvement for tar ?
On 12/9/06, Uwe Dippel <[EMAIL PROTECTED]> 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
Re: Bug in ksh // Improvement for tar ?
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.
Re: Bug in ksh // Improvement for tar ?
Otto Moerbeek <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
