On Mon, 2002-01-14 at 17:17, Massimiliano Mirra wrote:
> On Mon, Jan 14, 2002 at 12:08:58PM +0900, Chris Gehlker wrote:
> > On Macs, gnutar will be their if the user installed the optional
> > Developer Tools. It a pretty safe bet that she did in order to build
> > ruby in the first place.
> 
> Good, this leaves a door open.

No,  Hopefully there will be binary packages for the average-user to
install.  They might not have tar.

> > Backquotes work fine but 'tar' is not symlinked to gnutar. Rather it will
> > invoke BSD tar which, IIRC, needs an explicit z parameter to deal with .tgz
> > files. So you are better off  with
> > `tar -xzf #{pkgdir}`
> > Or
> > `gnutar xcf #{pkgdir}`
> 
> Sorry?  GNU tar needs a `z' parameter to deal with gzipped files, too.
> E.g. to pack:
> 
> tar zcf archive.tar.gz dir
> 
> And to unpack:
> 
> tar zxf archive.tar.gz
> 
> > I think the former will work on every BSD.
> 
> So it seems that we're not limited to GNU tar.  That's good news.

Also.  Using this format will work with ALL tar's (at least that I've
seen)

gzip -dc filename.tar.gz | tar xf -

That will work with a tar that doesn't take the z-flag.  And there is
alot of them.

> To summarize, the chances for tar as compression tool for packets are:
> 
> - Linux: will work everywhere.
> 
> - BSD: idem.
> 
> - Other Unices: idem, I guess.

Not at all.
lots of unices does
1) Not include a gnutar (but that's solvable as shown above)
2) Not include a gzip but only the old compress/uncompress programs.

If there is a way for gzip to create "compress"-archive (.Z normaly)
than we could use that for unix-compability because gzip will unpack .Z
without problem. I don't know if it can create them though. 

The only problem is that compress sucks.
 
> - Mac/Mac OS X: idem, as it is needed to install Ruby.

Again.. no

> - Windows: winzip could maybe do it.

Winzip costs money.  Don't expect everyone to have it.  I don't.
 
> - Hand helds: don't know.  Probably only those running Linux (iPAQ?).

My ipaq has both tar and gzip but don't count on it.

> Anyway, I'm somewhat biased for an all-Ruby solution, but a
> compression *format* (no matter its speed or ratio) is still something
> that must be chosen carefully.

I also believe in a all-Ruby solution.  I believe in using a
ruby/zlib-module and then coding something in it.  That would ofcourse
require everyone to install ruby/zlib but that's a one-time-thing.  I
feels more natural to install a library than to install binaries that
you might need to have in your path.

/Erik

-- 
Erik B?gfors               | erik / bagfors.nu
Supporter of free software | GSM +46 733 279 273
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32