[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
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
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
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
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
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
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
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
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,
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
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 `
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
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
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
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
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
* 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
#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
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.
== 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
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
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
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
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
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
- -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.
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
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
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
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
* 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
== 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
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
* 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
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
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
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
== 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
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,
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
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
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).
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
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
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
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
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
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
== 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
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
Hi,
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
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
52 matches
Mail list logo
