Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site circe.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!circe!gsp
From: gsp@circe.UUCP (Gary Perlman)
Newsgroups: net.cog-eng
Subject: standards, tools, history: options=?
Message-ID: <46@circe.UUCP>
Date: Sat, 24-Mar-84 13:29:05 EST
Article-I.D.: circe.46
Posted: Sat Mar 24 13:29:05 1984
Date-Received: Sun, 25-Mar-84 11:56:12 EST
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 71

Historically, development on UNIX was a public activity and universities
had near immediate access to work done at Bell Labs.  This is no longer true.
For something to get outside, it has to be approved by several levels of
management of several organizations in several companies.  This looks like
it will take several years on average.  My personal impression is that
there is some movement to release software supporting a standard UNIX
command line syntax.  Getopt, the parser referred to by several people
was a first attempt at this, but it was never released.  My conclusion is
that the worst way to put forth a standard is to keep it a secret.  My hope
is that Ralph Hill's wish of supporting software gets answered by the
powers that be.

Further elaborating on Hill's recent note, there is some consideration
of building command line parsing into the shell.  His suggestion is
full of merits, one of which not mentioned was program size and efficiency.
If the shell could have a parser added to it (adding pK text to the shell),
then some proportion of that coiuld be recovered from many programs.
Further, if the shell knew that a command line call to a program was invalid,
it would not have to fork and exec the program.  There are many other
tradeoffs, but the full discussion is in progress.

Also of substance is the proposal by Ian! D. Allen (-IAN! -> IAN=!)
that name=value more closely visually binds name and value than -name value.
I think he is right, Gestalt psychologists would claim he is right,
and there might even be some data supporting this, though I am not sure where.
I think it would be useful to bring up a distinction between ease of
comprehension and ease of expression in an artificial language like UNIX
syntax.  If name=value format is more easily comprehended by people,
it may still be the case that -n value format is just as easily expressed,
maybe even more so given the ability to bind single character names.
Most people are concerned with using UNIX syntax to express a command;
usually people do not read other users' commands.  An important exception to
this is when people are learning, either from watching others or reading
the UNIX manual.  The ability and preference of people to learn by example,
makes the comprehension of command syntax important.  The example of APL
being highly expressive and incomprehensible comes to mind.  Allen's example
of flag options eating up following arguments when misused is a valid comment.
If the `c' flag takes no value, then:
	c=value
would be easy to catch, but
	-c value
would not.  Further, if `c' takes a value, but none is supplied,
	-c -f ...
would cause `-f' to be eaten as the value.  The fix proposed by Hemenway
and Armitage for this is that option values are not optional.  While this
is not a solution (people will make mistakes and these should be detected)
there is some evidence that standard command line parsers will have type and
range checking so that obvious errors would be detected.

The argument (pardon the pun) about options (ugh) for options could be
volleyed back and forth until we are blue in the face.  I think most of
the major issues have been hashed, and they are good for people to know.
The final arbitrator is probably way up in AT&T for several reasons:
	1.  AT&T is in business and has paying customers for UNIX.
	2.  AT&T will support them by not pulling the rug out from under them.
	3.  AT&T will continue to be the largest single developer of UNIX tools.
	4.  All users, including universities, will want the improved tools.
	5.  Therefore, all users will accept the tools in AT&T's form, or
		spend their time reworking the tolls to fit their own standards.
These seem to be the facts of business life, at least as I understand them.
My own opinion is that if someone were going to design a command language
from scratch, the flag system would not be the one chosen, and probably
the name=value system would.  But a business has to live with its history.
And anyways, you wouldn't want to give up bundling options, would you?

Maybe the UNIX license should be changed from:
	UNIX -- live free or die
to
	UNIX -- love it or leave it

Gary Perlman	Bell Labs MH 5D-105	ulysses!gsp	x3624