Re: tar -I incompatibility
[cas] on every non-linux machine i have to use, the first thing i do is download and compile all the GNU tools including tar. i then change the PATH setting to include /usr/local/bin/gnu at the start. I used to do that, but then I got burned by 'df'. Debugging that one involved wading through pages and pages of very poorly written vendor ksh scripts, so I guess I learned my lesson. (In defense of GNU fileutils, I don't think I've seen any two Unix versions of df with compatible output either. The HP-UX 11 output is truly, ahem, interesting.) I've also been hit once trying to use bash as a root login shell. Some scripts that come with proprietary software actually don't have #! lines at the top, they just assume ksh. Oops. Yes, for the most part you can drop GNU utilities right in. But I no longer put them in front of the path for root or other system-oriented accounts. Peter
Re: Creeping featuritis (was: Re: tar -I incompatibility)
On Tue, Jan 09, 2001 at 06:23:44PM -0500, Jacob Kuntz wrote: from the secret journal of Sam Couter ([EMAIL PROTECTED]): No it's not. It does one thing (Advanced Package Management), and does it fairly well. Just because the thing it does is a complex task doesn't mean it's got creeping featuritis. If it tried to do more than just package management, that would be a different story. right, like if it tried to read mail or interpert lisp (which are the primary indicators of featuritis). I fail to see how these examples demonstrate that bzip2 options on tar are creeping featuritis. If anything, it demonstrates that it is not. It's not as if tar has bzip2/gzip built in. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: tar -I incompatibility
On Wed, Jan 10, 2001 at 04:24:32AM -0600, Peter Samuelson wrote: (In defense of GNU fileutils, I don't think I've seen any two Unix versions of df with compatible output either. The HP-UX 11 output is truly, ahem, interesting.) HPUX has a df and a bdf, as far as i remeber. and they ship a GNU Version in some extra dir. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: tar -I incompatibility
On Tue, Jan 09, 2001 at 02:06:52PM +1100, Sam Couter wrote: Hamish Moffatt [EMAIL PROTECTED] wrote: If we're expected to avoid any advanced features, why do the authors bother to implement them? http://www.tuxedo.org/~esr/jargon/html/entry/creeping-featuritis.html So, what's your point exactly? I hope you never use apt-get, as that would certainly be something beyond bare bones. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: tar -I incompatibility
On Sun, Jan 07, 2001 at 02:26:32PM +0100, Martin Bialasinski wrote: tar in potato uses -I for bzip2. So far, tar -I won't be bzip2 in woody, the next stable. I wonder how other linux distributions will handle this. Would it be possible for potato, to support -j as well to ease the transition to the new option? So anybody using debian could start using -j in their scripts. Then woody will start issue a warning for using -I . And how sure can we be the author won't change his mind on the -j option? Is -j fixed for the next stable tar version or will it probably change to something different again? If yes, we should not support -j in potato, as suggested above, of course. Ingo -- Disclosed Source programs mean software for which the source code is available without confidential or trade secret restrictions and for which the source code and object code are available for distribution without license charges.
Re: tar -I incompatibility
On Tue, Jan 09, 2001 at 09:09:06PM +0100, Ingo Saitz wrote: On Sun, Jan 07, 2001 at 02:26:32PM +0100, Martin Bialasinski wrote: tar in potato uses -I for bzip2. So far, tar -I won't be bzip2 in woody, the next stable. I wonder how other linux distributions will handle this. Would it be possible for potato, to support -j as well to ease the transition to the new option? So anybody using debian could start using -j in their scripts. Then woody will start issue a warning for using -I . Scripts should use --bzip2, which will probably be supported forever, and has the nice side effect of failing with tars that don't support it (rather than doing something unexpected). -- - mdz
Re: tar -I incompatibility
On Tue, Jan 09, 2001 at 09:09:06PM +0100, Ingo Saitz wrote: option? Is -j fixed for the next stable tar version or will it probably change to something different again? If yes, we should not support -j in potato, as suggested above, of course. It's already changed several times before. I would not rely on it not changing again. -- Mike Stone
Creeping featuritis (was: Re: tar -I incompatibility)
Hamish Moffatt [EMAIL PROTECTED] wrote: So, what's your point exactly? I hope you never use apt-get, as that would certainly be something beyond bare bones. No it's not. It does one thing (Advanced Package Management), and does it fairly well. Just because the thing it does is a complex task doesn't mean it's got creeping featuritis. If it tried to do more than just package management, that would be a different story. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgp7pr7N9pfVe.pgp Description: PGP signature
Re: Creeping featuritis (was: Re: tar -I incompatibility)
from the secret journal of Sam Couter ([EMAIL PROTECTED]): No it's not. It does one thing (Advanced Package Management), and does it fairly well. Just because the thing it does is a complex task doesn't mean it's got creeping featuritis. If it tried to do more than just package management, that would be a different story. right, like if it tried to read mail or interpert lisp (which are the primary indicators of featuritis). -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 12:28:15AM +1100, Hamish Moffatt wrote: Frankly, I don't see why gnu tar needs to be compatible with OS-specific versions because most of those are feature-poor anyway. the one reason for gnu tar to do that is so that it can be a drop-in replacement for those crappy versions. on every non-linux machine i have to use, the first thing i do is download and compile all the GNU tools including tar. i then change the PATH setting to include /usr/local/bin/gnu at the start. if the GNU commands were not backwards-compatible then it would be dangerous to do that. I agree with the suggestion that we modify tar for Debian to provide -I at least for compatibility for one more release. i think that whatever we do is going to be broken somehow. leaving it as -I means that GNU tar would no longer be a drop-in replacement for a proprietary tar. changing it to -j means that an upgraded GNU tar is no longer a drop-in replacement for older versions of GNU tar. both options suck. craig -- craig sanders
Re: tar -I incompatibility
From: Goswin Brederlow [EMAIL PROTECTED] Date: 07 Jan 2001 23:00:59 +0100 % tar -cIvvf bla.tar.bz2 bla tar: bla: Cannot stat: No such file or directory That is indeed a bug. Thanks for reporting it. I'll fix it as follows: @@ -439,5 +434,5 @@ or a device. *This* `tar' defaults to ` #define OPTION_STRING \ - -01234567ABC:F:GIK:L:MN:OPRST:UV:WX:Zb:cdf:g:hijklmoprstuvwxz + -01234567ABC:F:GI:K:L:MN:OPRST:UV:WX:Zb:cdf:g:hijklmoprstuvwxz static void That should change your scenario to behave something like this instead: % tar -cIvvf bla.tar.bz2 bla tar: vvf: Cannot open: No such file or directory tar: Error is not recoverable: exiting now which is a bit better (though admittedly not ideal). As I said before tar -I in its old useage should give one of several errors, but doesn't. Can't remeber the bug number, but its in the BTS. Sorry, I don't quite follow you here. On the other hand, just changing the meaning or deleting the option will result in severe breakage in 3rd party software. What 3rd party software do you have in mind?
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 08:32:33AM +1100, Sam Couter wrote: My point is that the -I option *doesn't* mean uncompress this file using bzip2 for anything other than GNU tar. Now that it doesn't mean that for GNU tar either, people are complaining. I think they probably shouldn't have been using -I to start with, at least not as a matter of habit or in scripts that might live for any decent length of time or have an application on any non-GNU system. If we're expected to avoid any advanced features, why do the authors bother to implement them? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: tar -I incompatibility
Hamish Moffatt [EMAIL PROTECTED] wrote: If we're expected to avoid any advanced features, why do the authors bother to implement them? http://www.tuxedo.org/~esr/jargon/html/entry/creeping-featuritis.html -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgprsCIGsT2lB.pgp Description: PGP signature
Re: tar -I incompatibility
On Sun, Jan 07, 2001 at 04:25:43AM +0100, Marcus Brinkmann wrote: On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin Brederlow wrote: tar -xIvvf file.tar.bz2 has been in use under linux for over a year by pretty much everybody. Even if the author never released it as stable, all linux distributions did it. I think that should count something. It tells a lot about the people making the distributions at least. Before making such snide comments, take a look at the changelog.Debian entries relating to the switch from 1.13 to 1.13.x. -- Mike Stone
Re: tar -I incompatibility
Goswin Brederlow [EMAIL PROTECTED] wrote: Just as linux-centric as the other way is solaris-centric. Not true. There's the way GNU tar works, then there's the way every other tar on the planet works (at least with respect to the -I option). GNU tar is (used to be) the odd one out. Now you're saying that not behaving like the odd man out is being Solaris-centric? I don't think so. sarcasm I like systems that don't change on a day to day basis. I don't want ls * to do rm * tomorrow just because some other unix does it and the author feels like it. /sarcasm I'm sure this has been said before, but: Don't run unstable if you don't like stuff changing or breaking. Unstable breaks stuff from time to time. It changes stuff more often than that. If options or behaviour changes from one update to the next, stiff bikkies. Deal with it in your own quiet little way. If that behaviour or option was non-standard to begin with, then think yourself lucky that you had it working as long as you did. tar -xIvvf file.tar.bz2 has been in use under linux for over a year by pretty much everybody. Even if the author never released it as stable, all linux distributions did it. I think that should count something. Enough to at least ease the transition. Pretty much everybody? I'd say you could modify that statement to pretty much everybody who doesn't deal with non-Linux systems often. The qualifier to that statement is very important. Ask someone who's actually used a non-Linux UNIX or UNIX-like system to explain it to you sometime. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgp9IMxwRKa2j.pgp Description: PGP signature
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 12:12:59AM +1100, Sam Couter wrote: Don't run unstable if you don't like stuff changing or breaking. Unstable breaks stuff from time to time. It changes stuff more often than that. This is a bit different, Sam. The I switch works in tar in potato. Your comment would apply if this were a temporary change and I would again work (ie compress with bzip2) by the time woody is released, but that's not the intention, is it? Frankly, I don't see why gnu tar needs to be compatible with OS-specific versions because most of those are feature-poor anyway. I agree with the suggestion that we modify tar for Debian to provide -I at least for compatibility for one more release. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: tar -I incompatibility
* Sam Couter [EMAIL PROTECTED] wrote: I'm sure this has been said before, but: Sure, but it doesn't apply here. Don't run unstable if you don't like stuff changing or breaking. tar in potato uses -I for bzip2. So far, tar -I won't be bzip2 in woody, the next stable. So anyone using just stable will be bitten by it. This has nothing to do with unstable. Ciao, Martin
Re: tar -I incompatibility
#include hallo.h
Nicolás Lichtmaier wrote on Sat Jan 06, 2001 um 05:35:55PM:
Or alias -I to -j, but print a warning to stderr:
tar: warning: Using the -I option for bzip compression is an obsolete
functionality and it will removed in future versions of tar,
Then, in the woody+1 we make -I work as upstream tar does now.
IMHO we should do it this way, but arrange with tar maintainers in other
distributions first. So Debian should not use this as the only
distribution while all others follows the upstream.
Gr{us,eeting}s,
Eduard.
--
Eduard Bloch [EMAIL PROTECTED]; HP: http://eduard.bloch.com/edecosi
0xEDF008C5(GnuPG): E6EB 98E2 B885 8FF0 6C04 5C1D E106 481E EDF0 08C5
**
Das wahrlich arnoootische daran ist, das wahrscheinlich _alle_
Regulars diesem Thread absolut faziniert folgen, nur traut sich keiner
was zu sagen, weil man die beiden ja offiziell im Killfile hat.
Alexander Stielau in de.alt.arnooo
Re: tar -I incompatibility
On Sun, Jan 07, 2001 at 02:05:27AM -0500, Michael Stone wrote: On Sun, Jan 07, 2001 at 04:25:43AM +0100, Marcus Brinkmann wrote: On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin Brederlow wrote: tar -xIvvf file.tar.bz2 has been in use under linux for over a year by pretty much everybody. Even if the author never released it as stable, all linux distributions did it. I think that should count something. It tells a lot about the people making the distributions at least. Before making such snide comments, take a look at the changelog.Debian entries relating to the switch from 1.13 to 1.13.x. I see. Well, I don't think that Bdale did something wrong with including 1.13.x. But I find the reactions to the flag change shown here by some people quite inappropriate. When using unreleased software, people have to expect such changes, especially for non-standard extensions. It happens all the time. In any way, sorry for the snide comment, it didn't reflect what I wanted to say, and thanks Michael for correcting me. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: tar -I incompatibility
== Marcus Brinkmann [EMAIL PROTECTED] writes: On Sun, Jan 07, 2001 at 02:05:27AM -0500, Michael Stone wrote: On Sun, Jan 07, 2001 at 04:25:43AM +0100, Marcus Brinkmann wrote: On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin Brederlow wrote: tar -xIvvf file.tar.bz2 has been in use under linux for over a year by pretty much everybody. Even if the author never released it as stable, all linux distributions did it. I think that should count something. It tells a lot about the people making the distributions at least. Before making such snide comments, take a look at the changelog.Debian entries relating to the switch from 1.13 to 1.13.x. I see. Well, I don't think that Bdale did something wrong with including 1.13.x. But I find the reactions to the flag change shown here by some people quite inappropriate. When using unreleased software, people have to expect such changes, especially for non-standard extensions. It happens all the time. On anything apart from Debian I wouldn't say a word about it. BUT on Debian tar -I is a standard and its stable. So I start screaming. Since the Debian maintainer made -I stable with a unstable upstream source, its his responsibility to watch it. Its the authors fault to have not resolved the problem for so long and suddenly resolve it in such a disasterous way, but also the Debian maintainers fault not to warn us and ease our transition. Fault might be a to strong word, I just mean that there should be a new upload asap that eigther reverts the -I change or tells the user about it. Having -I silently just do something else is not an option in my eyes. MfG Goswin
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 12:12:59AM +1100, Sam Couter wrote: Goswin Brederlow [EMAIL PROTECTED] wrote: Just as linux-centric as the other way is solaris-centric. Not true. There's the way GNU tar works, then there's the way every other tar on the planet works (at least with respect to the -I option). GNU tar is (used to be) the odd one out. Now you're saying that not behaving like the odd man out is being Solaris-centric? I don't think so. I have a lot of non-linux systems. Most of them don't have a -I operator on tar--that's why this is such a ludicrous argument. (Specifically, I checked Solaris, IRIX, AIX, HP/UX, and UNICOS. Only Solaris has a -I with the meaning now used in gnu tar. So yes, IME solaris is the odd man out and the change is solaris-centric.) Of the other flags I mentioned in a previous email (-Fiklop), *several* are found with different meanings on many tar implementations, yet no one seems interested in changing them. If someone uses multiple tar implementations he needs to read the man page; there is no other useful compatibility assumption. Changing gnu tar to be compatible with one of many diverse proprietary implementations, for only one of several incompatible flags, is a rationalization rather than a justification. sarcasm I like systems that don't change on a day to day basis. I don't want ls * to do rm * tomorrow just because some other unix does it and the author feels like it. /sarcasm I'm sure this has been said before, but: Don't run unstable if you don't like stuff changing or breaking. Bzzt. The stable version of tar is basically unusable because it contains several known bugs and is unmaintained. Upstream maintainer recommended following the so-called unstable tree to address those known bugs. Unstable breaks stuff from time to time. It changes stuff more often than that. If options or behaviour changes from one update to the next, stiff bikkies. Deal with it in your own quiet little way. If that behaviour or option was non-standard to begin with, then think yourself lucky that you had it working as long as you did. Most of the options in gtar are non-standard. Are you saying that users should rely on none of them? [snip] Ask someone who's actually used a non-Linux UNIX or UNIX-like system to explain it to you sometime. See above, and lose the condescension. People who use multiple platforms should know better than to assume behavior of tar flags across implementations. I don't know whether any amount of discussion will convince the upstream tar maintainers to undo this, but I certainly hope that the debian version at least prevents serious silent breakage by either reverting the change to -I and printing a message that the option is deprecated or removing the -I flag entirely. -- Mike Stone
Re: tar -I incompatibility
Sam == Sam Couter [EMAIL PROTECTED] writes: Sam Not true. There's the way GNU tar works, then there's the way every other Sam tar on the planet works (at least with respect to the -I option). GNU tar is Sam (used to be) the odd one out. Now you're saying that not behaving like the Sam odd man out is being Solaris-centric? I don't think so. Could you please name the other unices that behave identically to solaris tar wrt the -I option? And which other unices even have the -I option in tar? manoj -- Watch your mouth, kid, or you'll find yourself floating home. Han Solo Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: tar -I incompatibility
Michael Stone writes: (snip flamage) ms I don't know whether any amount of discussion will convince ms the upstream tar maintainers to undo this, but I certainly ms hope that the debian version at least prevents serious silent ms breakage by either reverting the change to -I and printing a ms message that the option is deprecated or removing the -I flag ms entirely. The tar maintainer is closing bug reports related to this problem as quickly as they come in, or else I would send this to the BTS, but for the meantime, here is an uncompiled patch: --- tar.c.orig Sun Oct 29 17:36:32 2000 +++ tar.c Sun Jan 7 12:39:57 2001 @@ -362,7 +362,7 @@ PATTERNat list/extract time, a globbing PATTERN\n \ -o, --old-archive, --portability write a V7 format archive\n\ --posixwrite a POSIX format archive\n\ - -j, --bzip2filter the archive through bzip2\n\ + -I, -j --bzip2 filter the archive through bzip2\n\ -z, --gzip, --ungzip filter the archive through gzip\n\ -Z, --compress, --uncompress filter the archive through compress\n\ --use-compress-program=PROGfilter through PROG (must accept -d)\n), @@ -371,7 +371,7 @@ \n\ Local file selection:\n\ -C, --directory=DIR change to directory DIR\n\ - -T, -I, --files-from=NAMEget names to extract or create from file NAME\n\ + -T, --files-from=NAMEget names to extract or create from file NAME\n\ --null -T reads null-terminated names, disable -C\n\ --exclude=PATTERNexclude files, given as a globbing PATTERN\n\ -X, --exclude-from=FILE exclude globbing patterns listed in FILE\n\ @@ -674,6 +674,11 @@ ignore_zeros_option = 1; break; + case 'I': + fprintf(stderr, +%s: Warning: the use of the I flag will soon mean --files-from +for compatibility with Solaris tar. Please use the j flag instead +when you mean --bzip2., program_name); case 'j': set_use_compress_program_option (bzip2); break; @@ -796,7 +801,7 @@ break; case 'T': - case 'I': /* for compatibility with Solaris tar */ +/* case 'I': /* for compatibility with Solaris tar */ files_from_option = optarg; break; -- Got jag? http://www.tribsoft.com
Re: tar -I incompatibility
Hello,
I think the -I == -j change is not that bad.
The only package I found using -I was devscripts' /usr/bin/uupdate.
I submitted this patch:
--- uupdate.origSun Jan 7 18:40:59 2001
+++ uupdate Sun Jan 7 18:43:13 2001
@@ -294,7 +294,7 @@
X=${ARCHIVE##*/}
case $X in
*.tar.gz) X=${X%.tar.gz}; UNPACK=tar zxf ;;
- *.tar.bz2) X=${X%.tar.bz2}; UNPACK=tar Ixf ;;
+ *.tar.bz2) X=${X%.tar.bz2}; UNPACK=tar --bzip2 -xf ;;
*.tar.Z) X=${X%.tar.Z}; UNPACK=tar zxf ;;
*.tgz) X=${X%.tgz}; UNPACK=tar zxf ;;
*.tar) X=${X%.tar}; UNPACK=tar xf ;;
Bastian Kleineidam
pgprqVOBKNKm9.pgp
Description: PGP signature
Re: tar -I incompatibility
Date: Sun, 7 Jan 2001 12:07:14 -0500 From: Michael Stone [EMAIL PROTECTED] I certainly hope that the debian version at least prevents serious silent breakage by either reverting the change to -I and printing a message that the option is deprecated or removing the -I flag entirely. Why would deprecating or removing the -I flag help prevent serious silent breakage? I would think that most people using -I in the 1.13.17 sense would use it like this: tar -xIf archive.tar and this silently breaks in 1.13.18 only in the unlikely case where f is a readable tar file. I'm not entirely opposed to deprecating -I for a while -- but I want to know why it's helpful to do this before installing such a change.
Re: tar -I incompatibility
- -j, --bzip2filter the archive through bzip2\n\ + -I, -j --bzip2 filter the archive through bzip2\n\ If it's a deprecated option, don't document it in the online help. A note in a COMPATIBILITY section in the manpage is more appropriate.
Re: tar -I incompatibility
On Sun, Jan 07, 2001 at 07:21:29PM +0100, [EMAIL PROTECTED] wrote: I think the -I == -j change is not that bad. The only package I found using -I was devscripts' /usr/bin/uupdate. The problem is not that it breaks our scripts -- it's different for every end user of tar as well! So if I'm used to using 'tar xIvf linux-2.4.0-test11.tar.bz2', that no longer works. Instead it's 'tar xjvf ...' Which is no better or worse than -I, except that it's different for reasons which don't apply to Debian. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: tar -I incompatibility
Manoj Srivastava [EMAIL PROTECTED] wrote: Could you please name the other unices that behave identically to solaris tar wrt the -I option? And which other unices even have the -I option in tar? My point is that the -I option *doesn't* mean uncompress this file using bzip2 for anything other than GNU tar. Now that it doesn't mean that for GNU tar either, people are complaining. I think they probably shouldn't have been using -I to start with, at least not as a matter of habit or in scripts that might live for any decent length of time or have an application on any non-GNU system. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpSPYMGYDdy5.pgp Description: PGP signature
Re: tar -I incompatibility
Michael Stone [EMAIL PROTECTED] wrote: Changing gnu tar to be compatible with one of many diverse proprietary implementations, for only one of several incompatible flags, is a rationalization rather than a justification. I agree, but it's at least as good (maybe better) a reason as the reason for adding -I in the first place. Yet people complain about it. Loudly and annoyingly. Bzzt. The stable version of tar is basically unusable because it contains several known bugs and is unmaintained. Upstream maintainer recommended following the so-called unstable tree to address those known bugs. I've been corrected several times on this comment. GNU tar is unstable because that's what the author says to use, and stable is broken and unmaintained. Similarly, the unstable version of GNU tar is in Debian stable, and will break systems when people upgrade to the next stable. I take the comment back, as I was in error. Most of the options in gtar are non-standard. Are you saying that users should rely on none of them? Pretty much. It's always useful to know exactly which options you're using are not going to work on many other systems, and to not form habits that involve the use of those options. The same argument is usually applied to programming: Don't use platform-specific features unless you need to. See above, and lose the condescension. People who use multiple platforms should know better than to assume behavior of tar flags across implementations. Sorry about the condescending tone. What I meant to get across is that people who regularly use other systems won't be in the habit of using -I or -z for that matter, and aren't likely to miss it. You can probably assume that -c, -x, -f and -v behave the same across implementations (modern implementations, anyway). That's about all, and isn't that enough for everything you'd every want to do with tar? -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpYJgRGzXEuO.pgp Description: PGP signature
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 12:12:59AM +1100, Sam Couter wrote: Goswin Brederlow [EMAIL PROTECTED] wrote: Just as linux-centric as the other way is solaris-centric. Not true. There's the way GNU tar works, then there's the way every other tar on the planet works (at least with respect to the -I option). GNU tar is (used to be) the odd one out. Now you're saying that not behaving like the odd man out is being Solaris-centric? I don't think so. I worked and still work on several paltform and the first think I usually do is make them compatible: compile bash, make, gcc, bash (again, to correct the stupid cc bugs), make, automake, autoconf, zsh, xemacs, tar, gzip, bzip2, qvwm. All the normal tools from comercial unixes are all proprietary to their system. The only way to standardise those is to use the free comon source of what we have under linux. So I say that what debian uses can be the default on all unix systems. Just my 2c. Goswin
Re: tar -I incompatibility
* Sam Couter [EMAIL PROTECTED] wrote: Michael Stone [EMAIL PROTECTED] wrote: Most of the options in gtar are non-standard. Are you saying that users should rely on none of them? Pretty much. It's always useful to know exactly which options you're using are not going to work on many other systems, and to not form habits that involve the use of those options. You can probably assume that -c, -x, -f and -v behave the same across implementations (modern implementations, anyway). That's about all, So, as you can not assume any particular flag for bzip2 compression anyway, why should GNU tar change its bzip2 option to the one used by the solaris tar? Ciao, Martin
Re: tar -I incompatibility
== Paul Eggert [EMAIL PROTECTED] writes: Date: Sun, 7 Jan 2001 12:07:14 -0500 From: Michael Stone [EMAIL PROTECTED] I certainly hope that the debian version at least prevents serious silent breakage by either reverting the change to -I and printing a message that the option is deprecated or removing the -I flag entirely. Why would deprecating or removing the -I flag help prevent serious silent breakage? I would think that most people using -I in the 1.13.17 sense would use it like this: tar -xIf archive.tar and this silently breaks in 1.13.18 only in the unlikely case where f is a readable tar file. % tar --version tar (GNU tar) 1.13.18 Copyright 2000 Free Software Foundation, Inc. This program comes with NO WARRANTY, to the extent permitted by law. You may redistribute it under the terms of the GNU General Public License; see the file named COPYING for details. Written by John Gilmore and Jay Fenlason. % tar -cIvvf bla.tar.bz2 bla tar: bla: Cannot stat: No such file or directory tar: Error exit delayed from previous errors % mkdir bla % tar -cIvvf bla.tar.bz2 bla drwxr-xr-x mrvn/mrvn 0 2001-01-07 22:50:27 bla/ % file bla.tar.bz2 bla.tar.bz2: GNU tar archive % tar -tIvvf bla.tar.bz2 drwxr-xr-x mrvn/mrvn 0 2001-01-07 22:50:27 bla/ As you see -I is silently ignored in violation to /usr/share/doc/tar/NEWS.gz: * The short name of the --bzip option has been changed to -j, and -I is now an alias for -T, for compatibility with Solaris tar. Thats part of the problem, people won't get any error message at the moment. Everything looks fine until you compare the size, run file or try to bunzip the file manually. As I said before tar -I in its old useage should give one of several errors, but doesn't. Can't remeber the bug number, but its in the BTS. I'm not entirely opposed to deprecating -I for a while -- but I want to know why it's helpful to do this before installing such a change. If its depreciated people will get a message every time they use -I. cron jobs will generate a mail every time they run. Just think how anoying a daily mail is and how fast people will change the option. BUT nothing will break, no data will be lost. On the other hand, just changing the meaning or deleting the option will result in severe breakage in 3rd party software. Sometimes without even giving a hint of the cause. You know how bad 3rd party software can be. :) MfG Goswin
Re: tar -I incompatibility
Martin Bialasinski [EMAIL PROTECTED] wrote: So, as you can not assume any particular flag for bzip2 compression anyway, why should GNU tar change its bzip2 option to the one used by the solaris tar? I'm not saying it *should* change the behaviour of the -I option. I'm saying that if it does, it does. I just don't want to hear complaints about a non-standard option suddenly behaving differently. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpKlL7DukBG1.pgp Description: PGP signature
Re: tar -I incompatibility
* Sam Couter [EMAIL PROTECTED] wrote: I'm not saying it *should* change the behaviour of the -I option. I'm saying that if it does, it does. I just don't want to hear complaints about a non-standard option suddenly behaving differently. The multiple-OS users do not benefit from this change (they can't rely on a standard bzip2 option), and users who use only GNU tar lose because of a incompatibility with prior GNU tar versions. If you take non-standard as GNU tar specific in your statement above, as it really is one by not being standard, this change is like dpkg switching around the meaning of -i and -r. I think that people can rightfully complain, if a program specific option is changed in a incompatible way. This is why we try to minimize incompatible changes and try to ease the transition if this is not possible. I don't see anyone getting an advantage from this change. Ciao, Martin
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 08:32:33AM +1100, Sam Couter wrote: My point is that the -I option *doesn't* mean uncompress this file using bzip2 for anything other than GNU tar. Now that it doesn't mean that for GNU tar either, people are complaining. I think they probably shouldn't have been using -I to start with, at least not as a matter of habit or in scripts that might live for any decent length of time or have an application on any non-GNU system. That's not much of a point at all. Why? First, it's obvious that someone wanted these functions or they wouldn't have been added to gnu tar. There are a lot of things, e.g., preserving atime or stripping /'s, that are quite useful and cannot be done in a portable fashion. Suggesting that people never use these functions is silly. Second, most installations I'm familiar with have various gnu utilities installed, tar being one of them. IOW, cross-platform compatibility is achieved by installing the same software on each platform. Doing that should give a user a reasonable chance of having the same options available on each platform--unless the program fails to maintain compatibility with itself. -- Mike Stone
Re: tar -I incompatibility
Goswin Brederlow wrote: the Author of tar changed the --bzip option again. This time its even worse than the last time, since -I is still a valid option but with a totally different meaning. This totally changes the behaviour of tar and I would consider that a critical bug, since backup software does break horribly with the new semantic. Yes, I think that this should definetely be changed back. The first time I encountered this problem, I thought that the tar.bz2 archive was broken from the error message tar reported. (Not a valid tar archive or so.) This change is confusing and unreasonable IMHO. Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :)
Re: tar -I incompatibility
Scott Ellis wrote: Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :) Well, ok, I didn't know about Solaris tar. Probably, they are right then, but nevertheless, it is a pain. Maybe there should be a debconf text message, priority low, that informs the user about it if Debconf is installed? Roland -- Roland Bauerschmidt [EMAIL PROTECTED]
Re: tar -I incompatibility
== Scott Ellis [EMAIL PROTECTED] writes: Goswin Brederlow wrote: the Author of tar changed the --bzip option again. This time its even worse than the last time, since -I is still a valid option but with a totally different meaning.This totally changes the behaviour of tar and I would consider that a critical bug, since backup software does break horribly with the new semantic. Yes, I think that this should definetely be changed back. The first time I encountered this problem, I thought that the tar.bz2 archive was broken from the error message tar reported. (Not a valid tar archive or so.) This change is confusing and unreasonable IMHO. Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :) The problem is that -I works although it should completly break everything. The only difference is that the tar file won't be compressed anymore. No warning, no error and noone reads changelogs unless something breaks. (well, most people don't). mkdir bla tar -cIvvf bla.tar.bz2 bla should give: bla.tar.bz2: No such file Since -I reads the files to be included from a file. bla: Failed to open file, bla is a directory Since tar should try to create a tra file named bla, which is a directoy. or tar: cowerdly refusing to create empty archiveSince there are no file given as parameters and none read from bla.tar.bz2. So where are the errors? MfG Goswin PS: Why not change the Solaris version to be compatible with the widely used linux version? I'm sure there are more people and tools out there for linux using -I then there are for solaris.
Re: tar -I incompatibility
Scott Ellis [EMAIL PROTECTED] wrote: Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I don't see the reasoning in the changelog, but I may just have missed it. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. Why not have portability, consistency, *and* backward compatibility? Make -I an alias for -j, problem solved. Unless Solaris tar has -I as an alias for -T - I suppose it must, as I can't think of any reason for such a blatantly incompatible change. I always use long options for nonstandard commands when building scripts anyway :) All the upstream tar people are doing is encouraging people to go back to 'bzip2 -dc foo.tar.bz2 | tar xvf -', I think. And, hell, if you want to be portable across Unixes you have to do that anyway. -- Colin Watson [EMAIL PROTECTED]
Re: tar -I incompatibility
On Sat, Jan 06, 2001 at 07:42:30AM -0500, Scott Ellis wrote: Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :) I think it would be best for *our* tar to move bzip to -j and *not have a -I at all*. -- Mike Stone
Re: tar -I incompatibility
Goswin Brederlow [EMAIL PROTECTED] writes: PS: Why not change the Solaris version to be compatible with the widely used linux version? I'm sure there are more people and tools out there for linux using -I then there are for solaris. One point the maintainer has made on the gnu mailing lists in response to complaints about this change is that there has actually been no *released* version of gnu tar that uses -I for bzip (I don't know whether it's true or not). -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
Re: tar -I incompatibility
On Sun, Jan 07, 2001 at 01:17:40AM +0900, Miles Bader wrote: One point the maintainer has made on the gnu mailing lists in response to complaints about this change is that there has actually been no *released* version of gnu tar that uses -I for bzip (I don't know whether it's true or not). Who cares? It adds no new functionality and is obviously breaking things. -- Mike Stone
Re: tar -I incompatibility
On Sat, Jan 06, 2001 at 11:20:58AM -0500, Michael Stone wrote: On Sun, Jan 07, 2001 at 01:17:40AM +0900, Miles Bader wrote: One point the maintainer has made on the gnu mailing lists in response to complaints about this change is that there has actually been no *released* version of gnu tar that uses -I for bzip (I don't know whether it's true or not). Who cares? It adds no new functionality and is obviously breaking things. I think that your argument is equivalent to someone complaining that unstable is broken. Of course it is, nothing has been finalized and it is, by definition, unstable. If you want stability, use the released version, not unstable or code in CVS, otherwise, realize that our first instincts are not always correct. -Neal pgpBDzmuz0Ht3.pgp Description: PGP signature
Re: tar -I incompatibility
On Sat, Jan 06, 2001 at 11:43:10AM -0500, Neal H Walfield wrote: I think that your argument is equivalent to someone complaining that unstable is broken. Of course it is, nothing has been finalized and it is, by definition, unstable. If you want stability, use the released version, not unstable or code in CVS, otherwise, realize that our first instincts are not always correct. NO. NO. NO. I've already heard it and I won't accept it. The so-called stable version of tar has *serious known bugs*. If upstream will not accept the responsibility of periodically updating tar with bug fixes, they must assume that people will follow the so-called unstable versions. Maybe, just maybe, upstream's instincts are wrong on the matter of -I also. Maybe, just maybe, if we hadn't followed upstream into using -I rather than -y we wouldn't be having a problem. Maybe we should just yank out -I and wait for upstream to catch up. Is there any guarantee that if we switch to -j it won't change again? -- Mike Stone
Re: tar -I incompatibility
Since solaris compat is now a release goal for tar, should we also expect dramatic changes in the behavior of the following options? (Some of these are actually supported on more platforms than just solaris; gtar is the only oddball.) F i k l o P -- Mike Stone
Re: tar -I incompatibility
Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :) I think it would be best for *our* tar to move bzip to -j and *not have a -I at all*. Or alias -I to -j, but print a warning to stderr: tar: warning: Using the -I option for bzip compression is an obsolete functionality and it will removed in future versions of tar, Then, in the woody+1 we make -I work as upstream tar does now.
Re: tar -I incompatibility
On Sat, Jan 06, 2001 at 02:53:06PM +, Colin Watson wrote: Scott Ellis [EMAIL PROTECTED] wrote: Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I don't see the reasoning in the changelog, but I may just have missed it. It's actually in the NEWS file: | * The short name of the --bzip option has been changed to -j, | and -I is now an alias for -T, for compatibility with Solaris tar. - Sebastian
Re: tar -I incompatibility
Goswin Brederlow [EMAIL PROTECTED] wrote: PS: Why not change the Solaris version to be compatible with the widely used linux version? I'm sure there are more people and tools out there for linux using -I then there are for solaris. This is an incredibly Linux-centric point of view. You sound worse than the BSD bigots. There are many, many, many different unices that are *not* Linux. You can't hope to change them all to be Just Like Linux (tm). You'll be lucky if any of them follow Linux behaviour, rather than the other way around. Hint: Adopt some cross-platform habits like: bzip2 -dc foo.tar.bz2 | tar xf - Not only will you then become more immune to changes in behaviour that was non-standard to begin with, you'll also find adjustment to other systems a lot easier. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgppqfa3DzFYe.pgp Description: PGP signature
Re: tar -I incompatibility
== Sam Couter [EMAIL PROTECTED] writes: Goswin Brederlow [EMAIL PROTECTED] wrote: PS: Why not change the Solaris version to be compatible with the widely used linux version? I'm sure there are more people and tools out there for linux using -I then there are for solaris. This is an incredibly Linux-centric point of view. You sound worse than the BSD bigots. Just as linux-centric as the other way is solaris-centric. Letting an option die out is bad. Changing an option name is evil. Chaning the meaning of an option to mean something else on the fly is pure evil[tm]. I think Debian should patch -I back to the old meaning. If compatibility with solaris tar is wanted, then let -I print a warning that its depreciated. In a few month give an error and maybe in a year adopt a new meaning for -I (if thats realy wanted). There are many, many, many different unices that are *not* Linux. You can't hope to change them all to be Just Like Linux (tm). You'll be lucky if any of them follow Linux behaviour, rather than the other way around. I don't want to change them but I also don't want to be changed by them in ways that are plain stupid. And the -I just changing meaning without any warning is plain stupid. Hint: Adopt some cross-platform habits like: bzip2 -dc foo.tar.bz2 | tar xf - Not only will you then become more immune to changes in behaviour that was non-standard to begin with, you'll also find adjustment to other systems a lot easier. sarcasm I like systems that don't change on a day to day basis. I don't want ls * to do rm * tomorrow just because some other unix does it and the author feels like it. /sarcasm tar -xIvvf file.tar.bz2 has been in use under linux for over a year by pretty much everybody. Even if the author never released it as stable, all linux distributions did it. I think that should count something. Enough to at least ease the transition. MfG Goswin
Re: tar -I incompatibility
On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin Brederlow wrote: tar -xIvvf file.tar.bz2 has been in use under linux for over a year by pretty much everybody. Even if the author never released it as stable, all linux distributions did it. I think that should count something. It tells a lot about the people making the distributions at least. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: tar -I incompatibility
Goswin Brederlow wrote: the Author of tar changed the --bzip option again. This time its even worse than the last time, since -I is still a valid option but with a totally different meaning. This totally changes the behaviour of tar and I would consider that a critical bug, since backup software does break horribly with the new semantic. Yes, I think that this should definetely be changed back. The first time I encountered this problem, I thought that the tar.bz2 archive was broken from the error message tar reported. (Not a valid tar archive or so.) This change is confusing and unreasonable IMHO. Roland -- Roland Bauerschmidt [EMAIL PROTECTED]
