[ On Sat, January 23, 1999 at 10:53:35 (-0800), Parag Patel wrote: ]
> Subject: Re: CVS commit: src 
>
> I have a getopt replacement that is almost completely backward 
> compatible, but also parses full or partial string arguments, numeric 
> arguments, and "+" options (which are also parsed as "--" options).

That sounds like a very good thing to have around.

However I don't think it should be terribly pertinent to the adoption of
long options for NetBSD command-lines.  Certainly something like this
would have to be made, should that decision be made, and it's good to
know there's at least one more freely available implementation.

There's also src/usr.bin/pr/egetopt.c, which I've been swaying back and
forth on suggesting that it should become a fully documented and
supported part of libc.

The real question is does NetBSD, or more properly do the majority of
NetBSD users, wish to join the GNU/Linux folks in taking what some will
argue as the next step beyond mere standards compliance and begin to
provide features which some people consider to be an advancement on mere
unix tools?  I won't detail any of the arguments for this -- there are
already several perfectly valid and convincing arguments in the GNU
"standards" document that'll already be installed on any NetBSD machine
where the GNU Automake package has been installed (See the info node
"Standards for Command Line Interfaces").

I don't think this would be an advantage for NetBSD, regardless of how
convincing these arguments might be.  Those of you who think NetBSD's
success depends on making it easy and attractive for GNU/Linux users to
switch to NetBSD will no doubt wish to argue against me, however I'm not
interested in that argument, nor does it seem The NetBSD Foundation is,
given their currently documented goals and expectations for NetBSD.
NetBSD already has its own unique advantages, and if it didn't we
wouldn't be using it in the first place.  I don't think many (any?)
people are forced to use NetBSD because of its unique features when
they'd much rather be using GNU/Linux because of that systems "enhanced"
command-line interface.  If the overwhelming majority of people can
provide valid and logical aruments as to why I'm wrong, then TNF should
update their documented goals and expectations (to effectively say that
they wish to sway GNU/Linux users onto the "right" path ;-) and those
who want long options should start submitting patches (and perhaps a
suite of volunteers should be picked to work directly on such a project
-- hopefully not adversely affecting the rate of current development on
more useful projects).  However up to now all I've seen are a couple of
totally unjustified statements from two developers and at least as many
sound justifications suggesting NetBSD users and at least one developer
agrees with me.

I should also note that doing this conversion, without at the same time
simply using the existing GNU utilities as the basis for the change,
would be a tremendously large undertaking, and to do it right would
indeed involve "breaking" some backwards compatability (where the use of
current options conflicts with GNU standardized options).  This would
also beg the question as to why NetBSD wouldn't join the Texinfo
revolution and convert all documentation to Texinfo format.  It also
would beg the question as to why NetBSD wouldn't simply use the GNU
utilities since they purportedly also include other enhancements,
extentions, fixes, and so on (providing GNU options while not providing
true GNU compatability would be looked on as futile by many folks).

I have several times discussed with friends and colleagues how
interesting it would be to create several unique user-level environments
on which any kernel could be hosted (yes, I meant to say it that way).
For example there could be a 4.4BSD user-land, a GNU user-land, and
perhaps even an NT or VMS or some other weird user-land.  One could then
boot the kernel of choice for the day, be it NetBSD, FreeBSD, Linux,
Hurd, or whatever on any of the available user-lands.  One could provide
all user-land environments simultaneously on a system and add a system
feature similar to Plan-9's bind() that would allow any given process to
pretend to live in any desired user-land.  Academically this is a very
interesting project, regarless of how practical it might turn out to be.
One can even imagine free operating system developers fragmenting into
separate user-land and kernel groups, each co-operating with each other
only to the degree necessary to ensure compatible APIs.

The reason for saying all this is essentially to point out that from the
average user's perspective they can already do this to a great extent
just by choosing GNU/Linux instead of *BSD, or vice versa.  The average
user doesn't care exactly how the kernel works, or whether or not the
source code for their system is in "Kernal Normal Form", etc.  They just
want to use the system, and if they feel more comfortable with, or find
some advantage in using, GNU utilities then they're going to either
install them on their current system (as is possible today with NetBSD)
or they'll chose a system that provides them as the core utilities.

-- 
							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>