> 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. > 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? > I usually use: > > gunzip < file.tar.gz | tar xf - Why can't everyone be more like you? 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. 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. David Galos
