[gentoo-user] star

[gentoo-user] star

[Florian Philipp]

Hi!

I'd like to hear some comments on app-arch/star.

I've looked at its (IMHO really great) man page and didn't see anything
obviously concerning. Most frequently used tar options (-c -x -p -z -j)
seem to be in place.

What I'd like to know: Is it fully backward compatible to tar? Could I
safely unmerge tar and make a symlink from tar to star?

Thanks in advance!

Florian Philipp
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] star

[Volker Armin Hemmann]

On Samstag, 22. September 2007, Florian Philipp wrote:
> Hi!
>
> I'd like to hear some comments on app-arch/star.
>
> I've looked at its (IMHO really great) man page and didn't see anything
> obviously concerning. Most frequently used tar options (-c -x -p -z -j)
> seem to be in place.
>
> What I'd like to know: Is it fully backward compatible to tar? Could I
> safely unmerge tar and make a symlink from tar to star?
>
> Thanks in advance!
>
> Florian Philipp

http://bulk.fefe.de/lk2006/bench.html

>Turns out that star can't do "star xzf -", it will say "Can only compress 
files." ROTFL! OK, so I used "|gzip -dc|star xf -" instead. What the hell.

seems that it is not 100% comaptible.

Since gnu tar, bsd tar and star each are different, I would not unmerge the 
gnu tar. Is there any reason not to use the gnu tar?
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] star

[Florian Philipp]

Volker Armin Hemmann schrieb:
> On Samstag, 22. September 2007, Florian Philipp wrote:
>> Hi!
>>
>> I'd like to hear some comments on app-arch/star.
>>
>> I've looked at its (IMHO really great) man page and didn't see anything
>> obviously concerning. Most frequently used tar options (-c -x -p -z -j)
>> seem to be in place.
>>
>> What I'd like to know: Is it fully backward compatible to tar? Could I
>> safely unmerge tar and make a symlink from tar to star?
>>
>> Thanks in advance!
>>
>> Florian Philipp
> 
> http://bulk.fefe.de/lk2006/bench.html
> 
>> Turns out that star can't do "star xzf -", it will say "Can only compress 
> files." ROTFL! OK, so I used "|gzip -dc|star xf -" instead. What the hell.
> 
> seems that it is not 100% comaptible.
> 
> Since gnu tar, bsd tar and star each are different, I would not unmerge the 
> gnu tar. Is there any reason not to use the gnu tar?

star supports p7zip which can be much better and especially more
flexible than bzip2, gzip and zip. Its other features (better
funcionality for acl, sparse files, recovery and backups among other
things) didn't sound bad, either.

If star were a fully qualified replacement for gnu tar, there would not
have been the need to keep it (and to produce possible inconsitency when
using both versions).

I used find and grep to search for any implementations of tar
compressing to stdout - I couldn't find any.

Although I don't trust my skills with regular expressions and the result
 of my test that much I'll do the following:
I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
to /bin/tar.

Let's see if it works.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] star

[Volker Armin Hemmann]

On Samstag, 22. September 2007, Florian Philipp wrote:
> Volker Armin Hemmann schrieb:
> > On Samstag, 22. September 2007, Florian Philipp wrote:
> >> Hi!
> >>
> >> I'd like to hear some comments on app-arch/star.
> >>
> >> I've looked at its (IMHO really great) man page and didn't see anything
> >> obviously concerning. Most frequently used tar options (-c -x -p -z -j)
> >> seem to be in place.
> >>
> >> What I'd like to know: Is it fully backward compatible to tar? Could I
> >> safely unmerge tar and make a symlink from tar to star?
> >>
> >> Thanks in advance!
> >>
> >> Florian Philipp
> >
> > http://bulk.fefe.de/lk2006/bench.html
> >
> >> Turns out that star can't do "star xzf -", it will say "Can only
> >> compress
> >
> > files." ROTFL! OK, so I used "|gzip -dc|star xf -" instead. What the
> > hell.
> >
> > seems that it is not 100% comaptible.
> >
> > Since gnu tar, bsd tar and star each are different, I would not unmerge
> > the gnu tar. Is there any reason not to use the gnu tar?
>
> star supports p7zip which can be much better and especially more
> flexible than bzip2, gzip and zip. Its other features (better
> funcionality for acl, sparse files, recovery and backups among other
> things) didn't sound bad, either.

I don't know - bzip2 is very good at 'recovery' because only the affected 
block is lost.

and if p7zip supports pipes, you don't need its support in tar. Just pipe 
from/to it.


>
> If star were a fully qualified replacement for gnu tar, there would not
> have been the need to keep it (and to produce possible inconsitency when
> using both versions).

as you can see, you need to play around with pipes anyway when you use star. 
So switching just because of one compression algo and become incompatible 
with the way emerge unpacks packages sounds pretty stupid IMHO.



-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

Florian Philipp <f.philipp@addcom.de> wrote:

> What I'd like to know: Is it fully backward compatible to tar? Could I
> safely unmerge tar and make a symlink from tar to star?

star is fully Posix compliant. GNU tar is not. In theory, there could
be problems with GNU tar tar archives if they are unpacked using star.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

Florian Philipp <f.philipp@addcom.de> wrote:

> star supports p7zip which can be much better and especially more
> flexible than bzip2, gzip and zip.

Uhm, what's bad about

        tar cf - | p7zip ....

> If star were a fully qualified replacement for gnu tar, there would not
> have been the need to keep it 

To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
have star: Star is made by Jörg Schilling, one of the biggest morons
on the earth. Guess why some distributions no longer use cdrecord but
switched to cdrkit?

> I used find and grep to search for any implementations of tar
> compressing to stdout - I couldn't find any.

What do you mean?

> I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
> to /bin/tar.
> 
> Let's see if it works.

Command line options aren't identical. I wouldn't wonder if you run
into problems.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:
> On Samstag, 22. September 2007, Florian Philipp wrote:

>> star supports p7zip which can be much better and especially more
>> flexible than bzip2, gzip and zip. Its other features (better
>> funcionality for acl, sparse files, recovery and backups among other
>> things) didn't sound bad, either.
> 
> I don't know - bzip2 is very good at 'recovery' because only the affected
> block is lost.

True - in theory. It doesn't help you much, if you lose a block in a
.tar.bz2 file, as the block sizes of bzip2 and tar won't overlap. Thus,
something like ".bz2.tar" would be better, meaning a tar which contains
pre compressed files. Granted, compression ratio would be worse.

If you want safety, I'd either suggest afio or maybe something like
par.

> and if p7zip supports pipes, you don't need its support in tar. Just pipe
> from/to it.

It does and that's the way it's supposed to be used on unix, according
to its manpage.

> as you can see, you need to play around with pipes anyway when you use
> star. So switching just because of one compression algo and become
> incompatible with the way emerge unpacks packages sounds pretty stupid
> IMHO.

ACK

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Florian Philipp]

Alexander Skwar schrieb:
> Florian Philipp <f.philipp@addcom.de> wrote:
> 
>> star supports p7zip which can be much better and especially more
>> flexible than bzip2, gzip and zip.
> 
> Uhm, what's bad about
> 
>         tar cf - | p7zip ....

It's a bit cumbersome to create a pipe each time I access an archive.
Well, I think I'll create a shell script or an alias for that.

> 
>> If star were a fully qualified replacement for gnu tar, there would not
>> have been the need to keep it 
> 
> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
> have star: Star is made by Jörg Schilling, one of the biggest morons
> on the earth. Guess why some distributions no longer use cdrecord but
> switched to cdrkit?
> 
>> I used find and grep to search for any implementations of tar
>> compressing to stdout - I couldn't find any.
> 
> What do you mean?
> 
Just that I used regular expressions to search for tar writing to
stdout, something that star can't, apparently. It seems it didn't work.
Not all but some emerge actions failed while using star.

>> I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
>> to /bin/tar.
>>
>> Let's see if it works.
> 
> Command line options aren't identical. I wouldn't wonder if you run
> into problems.
> 
Well, most are. I ran into problems anyway (see above). So, I'm back to
gnu tar.



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Stroller]

On 24 Sep 2007, at 09:30, Alexander Skwar wrote:
> ...
>> and if p7zip supports pipes, you don't need its support in tar.  
>> Just pipe
>> from/to it.
>
> It does and that's the way it's supposed to be used on unix, according
> to its manpage.

GNU tar features the -j, -z and -Z options. These are much more  
convenient than piping, and it would be nice to see p7zip supported  
in the same way.

Stroller.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Re: star

[Alexander Skwar]

Stroller <stroller@stellar.eclipse.co.uk> wrote:

> 
> On 24 Sep 2007, at 09:30, Alexander Skwar wrote:
>> ...
>>> and if p7zip supports pipes, you don't need its support in tar.
>>> Just pipe
>>> from/to it.
>>
>> It does and that's the way it's supposed to be used on unix, according
>> to its manpage.
> 
> GNU tar features the -j, -z and -Z options.

Yes, bad, isn't it? These options are not part of the Posix standard.
It would be good, if these superflous options wouldn't be present at
all. I say "superflous", as pipes work just fine.

> These are much more 
> convenient than piping, 

No.

> and it would be nice to see p7zip supported 
> in the same way.

No.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Re: star

[Alexander Skwar]

Florian Philipp <f.philipp@addcom.de> wrote:

> Alexander Skwar schrieb:
>> Florian Philipp <f.philipp@addcom.de> wrote:
>> 
>>> star supports p7zip which can be much better and especially more
>>> flexible than bzip2, gzip and zip.
>> 
>> Uhm, what's bad about
>> 
>>         tar cf - | p7zip ....
> 
> It's a bit cumbersome to create a pipe each time I access an archive.

Okay. I don't think so.

>>> I used find and grep to search for any implementations of tar
>>> compressing to stdout - I couldn't find any.
>> 
>> What do you mean?
>> 
> Just that I used regular expressions to search for tar writing to
> stdout, something that star can't, apparently.

star can write to stdout. "./star -c -f - . > ../s"

> It seems it didn't work. 

What is "it"?

> Not all but some emerge actions failed while using star.

No wonder. Command line options aren't compatible. And hell
will freeze before Mr. Schilling will change.

>>> I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
>>> to /bin/tar.
>>>
>>> Let's see if it works.
>> 
>> Command line options aren't identical. I wouldn't wonder if you run
>> into problems.
>> 
> Well, most are.

Not really. For GNU tar, "tar cf - . > ../s" would work. Not so 
for star.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Re: star

[b.n.]

Alexander Skwar ha scritto:
> Stroller <stroller@stellar.eclipse.co.uk> wrote:
> 
>> On 24 Sep 2007, at 09:30, Alexander Skwar wrote:
>>> ...
>>>> and if p7zip supports pipes, you don't need its support in tar.
>>>> Just pipe
>>>> from/to it.
>>> It does and that's the way it's supposed to be used on unix, according
>>> to its manpage.
>> GNU tar features the -j, -z and -Z options.
> 
> Yes, bad, isn't it? These options are not part of the Posix standard.
> It would be good, if these superflous options wouldn't be present at
> all. I say "superflous", as pipes work just fine.

It's not that an option becomes "bad" just because it's not carved into
the POSIX standard. What's important, I guess, is that tar is
POSIX-compliant, so that if you want, you can build POSIX-compliant
scripts etc. , but I can't see how non-POSIX but handy extensions could
be bad. Maybe it's me not seeing the problem. Maybe the POSIX standard
could just be extended as well. :)

>> and it would be nice to see p7zip supported 
>> in the same way.
> 
> No.

"No" means nothing. Tell us why.

m.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: star

[Alexander Skwar]

b.n. <brullonulla@gmail.com> wrote:

> Alexander Skwar ha scritto:
>> Stroller <stroller@stellar.eclipse.co.uk> wrote:
>> 
>>> On 24 Sep 2007, at 09:30, Alexander Skwar wrote:
>>>> ...
>>>>> and if p7zip supports pipes, you don't need its support in tar.
>>>>> Just pipe
>>>>> from/to it.
>>>> It does and that's the way it's supposed to be used on unix, according
>>>> to its manpage.
>>> GNU tar features the -j, -z and -Z options.
>> 
>> Yes, bad, isn't it? These options are not part of the Posix standard.
>> It would be good, if these superflous options wouldn't be present at
>> all. I say "superflous", as pipes work just fine.
> 
> It's not that an option becomes "bad" just because it's not carved into
> the POSIX standard.

To a degree, it is.

> What's important, I guess, is that tar is  
> POSIX-compliant, so that if you want, you can build POSIX-compliant
> scripts etc. ,

Depends. On the hand, you're right. But if non-compliant options
exist, people tend to use them. That's bad in so far, as they get
used to non-standard behaviour. That's especially bad, as standard
compliants solution exist.

> but I can't see how non-POSIX but handy extensions could 
> be bad. 

Let me give you a different example, although it has nothing
to do with POSIX.

Internet Explorer translates a \ in a URL to /. That's a non
standard compliant behaviour. Now, as many people (still *G*)
use IE, many people rely on that mis-behaviour of IE and make
it hard for non-misbehaving browsers (ie. Mozilla) to display
the content.

What does this have to do with GNU tar and it adding superflous
options? Quite a lot. -j et.al. are non-standard options. If a
(badly written) script relies on the presence of -j, this script
won't work with a POSIX compliant tar (like star or any Unix
tar (eg. Sun, HP, ...)). Is that bad? Yes, it is. It is bad, as
there's an easily accessible solution to this problem available:
Use pipes! In this case, the solution would be: 

        tar cf - dir | bzip2 > dir.tar.bz2
        tar cf - dir | 7z a -si dir.tar.7z

Or for decompression:

        bzcat dir.tar.bz2 | tar xf -
        7z x -so dir.tar.7z | tar xf -

> Maybe it's me not seeing the problem.

Yep.

> Maybe the POSIX standard  
> could just be extended as well. :)

Equally fine.

>>> and it would be nice to see p7zip supported
>>> in the same way.
>> 
>> No.
> 
> "No" means nothing. Tell us why.

Pipes exist. The current "integration" of 7-zip is fine. There's
no need to integrate other compression into tar. Actually, there's
no need at all to integrate ANY compression alg. into tar.

Furthermore, especially with 7zip, an integration into tar would
make the use of 7zip somewhat limited, as all of the additional
command line options of 7z would not be accessible anymore.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Tue, 25 Sep 2007 15:34:41 +0200, Alexander Skwar wrote:

> What does this have to do with GNU tar and it adding superflous
> options? Quite a lot. -j et.al. are non-standard options. If a
> (badly written) script relies on the presence of -j, this script
> won't work with a POSIX compliant tar

The script is only badly written if it is supposed to be POSIX
compliant. Additional features can enhance a program and make scripts
using it more readable/efficient/compact, providing the environment does
not require POSIX-compliance. e.g. portage can use tar-specific
enhancements if tar is in system on all profiles. 


-- 
Neil Bothwick

If at first you don't succeed, you'll get a lot of free advice from
folks who didn't succeed either.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Re: star

[Florian Philipp]

Alexander Skwar schrieb:
> Florian Philipp <f.philipp@addcom.de> wrote:
> 
>> Alexander Skwar schrieb:
>>> Florian Philipp <f.philipp@addcom.de> wrote:
>>>
>>>> star supports p7zip which can be much better and especially more
>>>> flexible than bzip2, gzip and zip.
>>> Uhm, what's bad about
>>>
>>>         tar cf - | p7zip ....
>> It's a bit cumbersome to create a pipe each time I access an archive.
> 
> Okay. I don't think so.
> 
I don't want to flame but does that mean that you are one of the guys
that always use the menu button when there's a hotkey available?

Yet, I agree with you in that it's not a good excuse for breaking POSIX
compliance, one more thing that can break. A bundle of scripts would be
better to wrap tar and *zip.

>>>> I used find and grep to search for any implementations of tar
>>>> compressing to stdout - I couldn't find any.
>>> What do you mean?
>>>
>> Just that I used regular expressions to search for tar writing to
>> stdout, something that star can't, apparently.
> 
> star can write to stdout. "./star -c -f - . > ../s"
> 

Ehhm, yes, it can. Sorry for that mistake. I really meant this behavior:
"Turns out that star can't do "star xzf -", it will say "Can only
compress files." (from Volker's first post).

>> It seems it didn't work. 
> 
> What is "it"?

Using find, grep and regular expressions to search for a case which
could trigger that misbehavior of star in order to find out whether I
can safely replace tar with star.

> 
>> Not all but some emerge actions failed while using star.
> 
> No wonder. Command line options aren't compatible. And hell
> will freeze before Mr. Schilling will change.
> 

I'm a bit puzzled. You wrote gnu tar is not POSIX compliant and now it's
star's fault that it doesn't work without modifying scripts?

>>>> I'll move /bin/tar to /bin/gnutar and make a symlink from /usr/bin/star
>>>> to /bin/tar.
>>>>
>>>> Let's see if it works.
>>> Command line options aren't identical. I wouldn't wonder if you run
>>> into problems.
>>>
>> Well, most are.
> 
> Not really. For GNU tar, "tar cf - . > ../s" would work. Not so 
> for star.
> 
> Alexander Skwar
> 

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] star

[Michael Schreckenbauer]

Hi,

Am Samstag, 22. September 2007 schrieb Florian Philipp:
> Hi!
> I'd like to hear some comments on app-arch/star.

it's a great tool imo.

> I've looked at its (IMHO really great) man page and didn't see anything
> obviously concerning. Most frequently used tar options (-c -x -p -z -j)
> seem to be in place.
> What I'd like to know: Is it fully backward compatible to tar?

What version of "tar"? It's not 100% compatible to GNU tar but posix compliant 
afaik.

> Could I 
> safely unmerge tar and make a symlink from tar to star?

Well I did the symlink, but have a copy of gnu tar in some other dir. Until 
now, I did not need the fallback.

> Thanks in advance!
> Florian Philipp

Hth,
Michael

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Michael Schreckenbauer]

Am Montag, 24. September 2007 schrieb Alexander Skwar:
> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
> have star: Star is made by Jörg Schilling, one of the biggest morons
> on the earth. Guess why some distributions no longer use cdrecord but
> switched to cdrkit?

Keep your private rants offlist please. Your personal opinions on Jörg 
Schilling are completly irrelevant.

Regards,
Michael

--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[b.n.]

Michael Schreckenbauer ha scritto:
> Am Montag, 24. September 2007 schrieb Alexander Skwar:
>> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
>> have star: Star is made by Jörg Schilling, one of the biggest morons
>> on the earth. Guess why some distributions no longer use cdrecord but
>> switched to cdrkit?
> 
> Keep your private rants offlist please. Your personal opinions on Jörg 
> Schilling are completly irrelevant.

I agree it was not a nice rant, but it's not an irrelevant opinion,
because Schilling -let's say- idiosyncratic personality, has led, as
Alexander pointed out, to the disapperance of cdrecord from most Linux
distros and its substitution with cdrkit, for example.

The problem is that of a tool that for licence etc. problems could be
easily be dropped from a distribution. It's of a relatively unreliable
developer (or, better stated, of unrealiable relationships between the
dev and the community). Given this, I would think twice before
substituting tar with a Schilling tool. The cdrecord scar is still painful.

m.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Re: star

[Alexander Skwar]

Neil Bothwick <neil@digimed.co.uk> wrote:

> On Tue, 25 Sep 2007 15:34:41 +0200, Alexander Skwar wrote:
> 
>> What does this have to do with GNU tar and it adding superflous
>> options? Quite a lot. -j et.al. are non-standard options. If a
>> (badly written) script relies on the presence of -j, this script
>> won't work with a POSIX compliant tar
> 
> The script is only badly written if it is supposed to be POSIX
> compliant. Additional features can enhance a program 

Given that we're talking about use of non-standard options present
only in GNU tar vs. easily accessible standard compliant ways
of solving the same problem: No, a script is badly written, if it
makes use of non-standard options.

> and make scripts 
> using it more readable/efficient/compact, providing the environment does
> not require POSIX-compliance. e.g. portage can use tar-specific
> enhancements if tar is in system on all profiles.

Yes, it's very bad that Gentoo scripts don't limit themselves to 
POSIX. Another windmill to fight against.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Hello Alexander Skwar,

> Yes, it's very bad that Gentoo scripts don't limit themselves to 
> POSIX. Another windmill to fight against.

Artificially limiting yourself to the lowest common denominator when
better options are available is bad, and discourages evolution. POSIX
specifies the minimum set of options and features, not the maximum. As
long as the standards aren't broken, nothing is wrong, and adding new,
useful and compatible features is one way that standards get improved.


-- 
Neil Bothwick

I don't know what makes you tick but I wish it was a time bomb.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: star

[Alexander Skwar]

Neil Bothwick <neil@digimed.co.uk> wrote:

> Hello Alexander Skwar,
> 
>> Yes, it's very bad that Gentoo scripts don't limit themselves to
>> POSIX. Another windmill to fight against.
> 
> Artificially limiting yourself to the lowest common denominator when
> better options are available is bad, and discourages evolution.

Well, depends.

Making use of non standard options when standard compliant
options are avialable, is no-good evolution. It very much
tastes of the way Microsoft handles standards. Eg. have a
look at how MS treated Java or HTML (granted, Netscape wasn't
much better either).

Back to tar: Why use "tar -j" in scripts, when "bzip2 | tar"
does the same thing? I very much disagree that "tar -j" is
the "better" option here; in fact, I'd say that "bzip2 | tar"
is the better option, as it works on a lot more systems than
"tar -j" does. Heck, "tar -j" even does not work on all GNU
tar implementations, as very old GNU tars don't have bzip2
support at all and -j wasn't always used for bzip2.

> POSIX 
> specifies the minimum set of options and features, not the maximum. As
> long as the standards aren't broken, nothing is wrong, and adding new,
> useful and compatible features is one way that standards get improved.

No, it's not. To improve a standard, you make sure that the standard
gets amended and then you implement something. Not the other way around.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Wed, 26 Sep 2007 10:14:58 +0200, Alexander Skwar wrote:

> Back to tar: Why use "tar -j" in scripts, when "bzip2 | tar"
> does the same thing? I very much disagree that "tar -j" is
> the "better" option here;

Either way requires that you first determine the type of compression used
before you can decide where to pipe tar's output, if at all. Whereas
something like "tar xf somefile" avoids the need to do" file somefile"
and parse the output first.

> in fact, I'd say that "bzip2 | tar"
> is the better option, as it works on a lot more systems than
> "tar -j" does. Heck, "tar -j" even does not work on all GNU
> tar implementations, as very old GNU tars don't have bzip2
> support at all and -j wasn't always used for bzip2.

If you don't know the details of the platform running your script, you
should of course stick to POSIX, which tar can do fine. But if your
script in running in an environment you control, why not make use of more
efficient methods?


> > POSIX 
> > specifies the minimum set of options and features, not the maximum. As
> > long as the standards aren't broken, nothing is wrong, and adding new,
> > useful and compatible features is one way that standards get
> > improved.  
> 
> No, it's not. To improve a standard, you make sure that the standard
> gets amended and then you implement something. Not the other way around.

That's not how evolution works. Things are tried, some (most) fall by the
wayside and others are accepted. As long as you don't break the standard
with your enhancements, where's the harm in improvement? I know car
analogies are tired, but it's like arguing that all cars should be
designed to meet the minimum standards required by law, and if the law
doesn't stipulate air conditioning, we don't need it - that example is
usually true here in the UK :(


-- 
Neil Bothwick

The fact that no one understands you doesn't mean you're an artist.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Re: star

[Alexander Skwar]

Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 26 Sep 2007 10:14:58 +0200, Alexander Skwar wrote:
> 
>> Back to tar: Why use "tar -j" in scripts, when "bzip2 | tar"
>> does the same thing? I very much disagree that "tar -j" is
>> the "better" option here;
> 
> Either way requires that you first determine the type of compression used
> before you can decide where to pipe tar's output, if at all. Whereas
> something like "tar xf somefile" avoids the need to do" file somefile"
> and parse the output first.

Pardon? "tar xf somefile" doesn't do any compression at all.
I don't get what you mean.

>> in fact, I'd say that "bzip2 | tar"
>> is the better option, as it works on a lot more systems than
>> "tar -j" does. Heck, "tar -j" even does not work on all GNU
>> tar implementations, as very old GNU tars don't have bzip2
>> support at all and -j wasn't always used for bzip2.
> 
> If you don't know the details of the platform running your script, you
> should of course stick to POSIX, which tar can do fine.

No, GNU tar is not completely POSIX compliant. The files it creates
don't completely comply to the standard. But that's another story.

> But if your 
> script in running in an environment you control, why not make use of more
> efficient methods?

If there are more efficient methods: Maybe. But if the non standard
options aren't more efficient, why use them at all? "tar -j" is a
good example here: Internally, tar invokes the external "bzip2" 
command. So with "tar | bzip2" vs. "tar -j", both are equally
efficient.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Wed, 26 Sep 2007 10:45:51 +0200, Alexander Skwar wrote:

> > Either way requires that you first determine the type of compression
> > used before you can decide where to pipe tar's output, if at all.
> > Whereas something like "tar xf somefile" avoids the need to do" file
> > somefile" and parse the output first.  
> 
> Pardon? "tar xf somefile" doesn't do any compression at all.
> I don't get what you mean.

No, but it does do whatever decompression is required. Of course, you do
have to specify a compression method when creating a compressed archive.


-- 
Neil Bothwick

If only the good die young then what does that say about senior citizens?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: star

[Michael Schreckenbauer]

Am Mittwoch, 26. September 2007 00:26:51 schrieb b.n.:
> Michael Schreckenbauer ha scritto:
> > Am Montag, 24. September 2007 schrieb Alexander Skwar:
> >> To keep GNU tar, you mean? Well, there's at least a reason to not ONLY
> >> have star: Star is made by Jörg Schilling, one of the biggest morons
> >> on the earth. Guess why some distributions no longer use cdrecord but
> >> switched to cdrkit?
> >
> > Keep your private rants offlist please. Your personal opinions on Jörg
> > Schilling are completly irrelevant.
>
> I agree it was not a nice rant, but it's not an irrelevant opinion,
> because Schilling -let's say- idiosyncratic personality, has led, as
> Alexander pointed out, to the disapperance of cdrecord from most Linux
> distros and its substitution with cdrkit, for example.

and I for myself drop cdrkit in every place I find it and replace it with the 
imo working tool named cdrecord. 

> The problem is that of a tool that for licence etc. problems could be
> easily be dropped from a distribution. It's of a relatively unreliable
> developer (or, better stated, of unrealiable relationships between the
> dev and the community).

I have no problems at all with Jörg, quite the opposite.

> Given this, I would think twice before 
> substituting tar with a Schilling tool. The cdrecord scar is still painful.

Good programmers often have big egos. See Linus for an example. When will 
distributions drop the kernel, because Linus made bad comments about gnome, 
cups or some other random program?
The tool (star, cdrecord) works, is well supported and the programmer reacts 
in time to requests. What else do you expect?

> m.

Greetings,
Michael
--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Re: star

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Wednesday 26 September 2007 10:59:00 Neil Bothwick wrote:
> > Pardon? "tar xf somefile" doesn't do any compression at all.
> > I don't get what you mean.
>
> No, but it does do whatever decompression is required. Of course, you do
> have to specify a compression method when creating a compressed archive.

Heh. unpack() doesn't even take advantage of that. It also doesn't use -j but 
it does use z to decompress tar.gz files.. ;)

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Re: Re: star

[Alexander Skwar]

Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 26 Sep 2007 10:45:51 +0200, Alexander Skwar wrote:
> 
>> > Either way requires that you first determine the type of compression
>> > used before you can decide where to pipe tar's output, if at all.
>> > Whereas something like "tar xf somefile" avoids the need to do" file
>> > somefile" and parse the output first.
>> 
>> Pardon? "tar xf somefile" doesn't do any compression at all.
>> I don't get what you mean.
> 
> No, but it does do whatever decompression is required.

Hey, that's a nice feature. I didn't know about that.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Re: Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Wed, 26 Sep 2007 12:08:11 +0200, Alexander Skwar wrote:

> > No, but it does do whatever decompression is required.  
> 
> Hey, that's a nice feature. I didn't know about that.

Be careful, it is not part of the POSIX standard and may cause premature
hair loss ;-)


-- 
Neil Bothwick

Klingons do NOT sweat! They perspire with honour!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Re: star

[Volker Armin Hemmann]

On Mittwoch, 26. September 2007, Alexander Skwar wrote:
> Neil Bothwick <neil@digimed.co.uk> wrote:
> > On Tue, 25 Sep 2007 15:34:41 +0200, Alexander Skwar wrote:
> >> What does this have to do with GNU tar and it adding superflous
> >> options? Quite a lot. -j et.al. are non-standard options. If a
> >> (badly written) script relies on the presence of -j, this script
> >> won't work with a POSIX compliant tar
> >
> > The script is only badly written if it is supposed to be POSIX
> > compliant. Additional features can enhance a program
>
> Given that we're talking about use of non-standard options present
> only in GNU tar vs. easily accessible standard compliant ways
> of solving the same problem: No, a script is badly written, if it
> makes use of non-standard options.

a script that is not supposed to be portable to a POSIX-only system, can be 
written in any way the host system supports. So it is not 'broken' nor 'badly 
written'. Please calm down. Ok?

>
> > and make scripts
> > using it more readable/efficient/compact, providing the environment does
> > not require POSIX-compliance. e.g. portage can use tar-specific
> > enhancements if tar is in system on all profiles.
>
> Yes, it's very bad that Gentoo scripts don't limit themselves to
> POSIX. Another windmill to fight against.
>

no.

Please stop that nonesense, ok? Gentoo scripts are gentoo scripts. Not AIX, 
Solaris or HP-UX scripts (systems who are very arcane in a lot of aspects). 
So gentoo scripts don't need to be portable, so they don't need to be POSIX 
compliant. And since gentoo is a linux distribution and almost all linux 
distributions use the gnu-userland, gnu-compatibility is more than enough for 
portability to other linux distributions.

And some last questions: if POSIX is so great, why is there stuff 
like 'SUS', 'LSB', and why has POSIX many different versions?


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[b.n.]

Michael Schreckenbauer ha scritto:
> and I for myself drop cdrkit in every place I find it and replace it with the 
> imo working tool named cdrecord. 

Sure, your choice.

>> The problem is that of a tool that for licence etc. problems could be
>> easily be dropped from a distribution. It's of a relatively unreliable
>> developer (or, better stated, of unrealiable relationships between the
>> dev and the community).
> 
> I have no problems at all with Jörg, quite the opposite.

It's not *you* that has to have problems with him. It's distributions.
See below.

>> Given this, I would think twice before 
>> substituting tar with a Schilling tool. The cdrecord scar is still painful.
> 
> Good programmers often have big egos. See Linus for an example. When will 
> distributions drop the kernel, because Linus made bad comments about gnome, 
> cups or some other random program?
> The tool (star, cdrecord) works, is well supported and the programmer reacts 
> in time to requests. What else do you expect?

The problem with cdrecord (and J.S.) is that in a new version of
cdrecord he bundled CDDL and GPL code together, thinking that it's right
to distribute such an hybrid binary.
Debian and a large number of other distros think instead that you cannot
legally distribute a CDDL+GPL hybrid thing. So, to avoid legal concerns,
they had to remove cdrecord from the distribution and fork the last GPL
(or CDDL?)-only version of cdrecord.

In our case: if you use a tool like that in your scripts and suddenly
the Gentoo devs feel that tool has to be removed/replaced (not the case
of cdrtools in Gentoo apparently, but...), you are in trouble. It's not
matter of who is right/who is wrong (I personally have no serious
opinion on that, because I didn't enter into the issue), but J.S.
refused any attempt to settle down the problem with the Linux
distribution, only putting blame on them and telling them "oh who cares,
f**k you". That's why someone has harsh opinions on him and can't trust
relying on his tools.

OTOH, I agree he's a truly skilled developer.

m.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: star

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Wed, 26 Sep 2007 19:44:20 +0200, b.n. wrote:

> In our case: if you use a tool like that in your scripts and suddenly
> the Gentoo devs feel that tool has to be removed/replaced (not the case
> of cdrtools in Gentoo apparently, but...), you are in trouble.

In this case, that shouldn't be a problem, because the cdrkit ebuild
installs cdrecord and mkisofs as symlinks to wodim and genisoimage
respectively.


-- 
Neil Bothwick

Top Oxymorons Number 41: Good grief

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]