[ On Tue, January 26, 1999 at 08:18:33 (-0500), Todd Vierling wrote: ]
> Subject: Re: deprecating long options in tar and cpio (was: CVS commit: src)
>
> Then you have about a dozen options each which need a short option
> equivalent.  --exclude, --numeric-uids, --no-recursion come to mind.  (The
> latter is in gtar 1.12, and I do intend to add it to pax as soon as longopts
> are there.)  You're getting rather low on letters in tar....

If you want GNU Tar, then use GNU Tar.  If you want pax, then use pax.
Pax's tar command-line interface exists because of it's original design
goal -- as a way of creating peace (pax!) in the almost ancient tar/cpio
wars that had long plagued the East/West division of the Unix empire.

NetBSD added GNU Tar (and GNU Cpio), possibly back when it was
discovered that AT&T's "tar" (and "cpio") had infected the original
4.3net2 distribution, in what I've alwasy considered to be a somewhat
misguided attempt to provide a tool for handling "tar" files (and GNU
Cpio for "cpio" files).  Of course "tar" files were the common format
for system installation media so something was necessary to handle them.
At the time there was no BSD pax, but there was the original pax
implementation which was already at that time far superior in quality to
either GNU Tar or GNU Cpio, and which of course provided a traditional
"tar" and "cpio" optional command-line interface so as to meet its
original mandate.  I may even have tried to publicly sway NetBSD in the
direction of the original pax implementation back then, but my memory
of this has faded.  I wasn't so concerned back then with the GNU'ness of
GNU Tar (nor am I really today), as with the bugs it had(has!) and it's
extremely non-standard nature.

4.4BSD-Lite (and Lite2) has neither a real "tar" nor a real "cpio", and
instead offers a new BSD pax with "tar" and "cpio" compatability modes.
It surprised me that NetBSD didn't immediately drop GNU Tar and GNU Cpio
in favour of the new BSD pax that came with 4.4 back when the 4.4
merging started, especially given the desire to rid the NetBSD tree of
code covered by the GNU copyright (of which of course GNU Tar and GNU
Cpio are covered by).

BSD pax already has an equivalent to "--exclude" (though it may not be
quite as flexible unless it can appear in the midst of a group of
patterns to negate those that follow it).

Do you mean "--numeric-owner" instead of "--numeric-uids"?  I think pax
already does the right thing, and has '-p o' to preserve the UID and
GID, though it could use better documentation of how it handles the
uid/gid vs. uname/gname fields of POSIX 1003.1 archives, and perhaps
there could be command-line options to explicitly select between one or
the other.  At the moment I'd have to read the source to determine
exactly what it does in various circumstances.

The '-d' option to pax is equivalent to GNU Tar's "--no-recursion".

> Exactly how does having longopts for compatibility (and the ability to have
> more than 52 options) *hurt* you?

Well, it's not me that I'm thinking about.  It's all those users out
there who will be confused by BSD pax having some long options, and yet
nothing else in NetBSD offers long options.  Further pax/tar/cpio with
long options will not necessarily be 100% compatible (especially on a
bug-for-bug comparison) with GNU Tar (and GNU Cpio) and whether this
will be a good thing or not is difficult to tell.

I think NetBSD should use pax throughout and offer the "tar" and "cpio"
optional command-line interfaces to pax as simply legacy interfaces and
as such those legacy interfaces should comply *only* with The Single
UNIX Specification interfaces.  People who want GNU Tar and/or GNU Cpio
can easily install them using the package system.  Of course all NetBSD
tools that use "tar" or "cpio" need to be fixed to use "pax" instead,
and if there are any features missing from "pax" that are required by
any existing (or future) NetBSD tools then they need to be added to
"pax".  As I said, I'm willing to help transition through this change by
patching GNU Tar and GNU Cpio to warn of non-standard usage, and to help
update pax to support any missing features (for instance I'd like to see
pax use zlib instead instead of a separate gzip process).

I believe the issue of supporting long options in the larger context of
the entire tool suite.  I would argue that both Jason and I have shown
that it is not in any way necessary for NetBSD to offer long option
support only in the "tar" (or "cpio") interfaces.  I personally don't
see any point to supporting long options in all NetBSD commands, since
this would be over and above the call for standards compliance and
especially since there's already a well maintained tool-set which can
easily be installed on NetBSD to offer these enhancements.  However I
would not object to a gradual move in this direction so long as a
sufficiently large number of NetBSD users would appreciate it, and so
long as there's no threat of losing existing NetBSD users due to the
potential bad politics such a change may (or may not) introduce, and on
the condition that this "goal" be documented in NetBSD and on the
www.netbsd.org web pages.  I just won't be very enthusiastic about
submitting patches to reach this goal.  ;-)  I'll only get enthusiastic
when some standards group mandates long options.

Pax is certainly not anywhere near needing more namespace for options,
at least not yet.  ls(1) is probably the only command getting tight for
command-line namespace, but it's still a long ways from 52 options.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>