Re: [dev] [sbase] Adding tar
Why don't we just use popen?
On Jul 7, 2013 3:24 AM, "Markus Wichmann" <nullplan_AT_gmx.net> wrote:
> On Sat, Jul 06, 2013 at 10:53:01PM -0500, Galos, David wrote:
> > > I also see it a lot in scripts, along with using full options instead
> > > of short--perhaps to be more verbose? So, for compatibility, perhaps it
> > > is best to allow both.
> > If you mean GNU --long-options, then never in a million years :) If
> > you mean both dashed and non, that is likely what I will do.
> >
> > Based on the very high incidence of use of non-dashed options, their
> > inclusion is justifiable. In order to nicely support this, I think
> > that the best option will be to attempt ARGBEGIN parsing, and as long
> > as no flags are present, to fall back on simple non-dashed parsing.
> >
>
> You also could roll your own option parser. Which in this case is called
> for, I think.
>
> > > tar xzf filename.tar.gz -C ~/scratch/
> > Crap.
> > The -C flag seems like a good idea, but why'd you have to go
> > and mix dashed and non like that?
> >
>
> One way I also find myself using quite often:
>
> tar xfC filename.tar.gz directory
> tar xCf directory filename.tar.gz
>
> > > I usually use:
> > >
> > > gunzip < file.tar.gz | tar xf -
> > Why can't everyone be more like you?
> >
>
> Convenience. ;-)
>
> > I see that a lot of people rely on tar's integration with
> gzip,bzip2,xz,etc.
> > Although convenient, it sucks, because that exact functionality can
> > be so beautifully achieved with pipelines. Using a shell script to wrap
> > tar with compression is trivial, but also defeats the whole point of
> > complicating tar's option parsing for compatibility reasons.
> >
>
> You are right, of course. I have also seen problems with this approach
> when it comes to parallelizing the decompression step (with the pipe
> approach you can swap gzip for a parallel version of gzip, with the gtar
> compression autodetection you cannot short of hacks like symlinking you
> parallel gzip to gzip and putting it first in PATH or so).
>
> > For now, tar will not do compression. If sbase gains programs to do
> > compression, and the code is nicely librarized, I will consider thinking
> > about considering adding letting tar do that.
> >
>
> Wait, libz and libbz2 and xzlib are not suckless enough?
>
> >
> > David Galos
>
> Ciao,
> Markus
>
>
Received on Sun Jul 07 2013 - 15:14:09 CEST
This archive was generated by hypermail 2.3.0
: Sun Jul 07 2013 - 15:24:05 CEST