Why don't we just use popen? On Jul 7, 2013 3:24 AM, "Markus Wichmann" <nullp...@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 > >
