standardized error messages

[John Quarterman]

From: John Quarterman (moderator) <std-unix-request at ut-sally>
Topic: standardized error messages

The idea proposed in this message has been proposed before in this newsgroup.
I am letting it through anyway, since this is a more complete description
of the idea.  After the flurry of rebuttals which will no doubt ensue,
I would prefer we not rehash it yet a third time.

If the discussion devolves into a TOPS-20 vs. UNIX flaming match, I will
at some point (soon) arbitrarily cut it off.

----------------------------------------------------------------------

Date: Fri, 5 Jul 85 12:25:33 est
From: Stephen Uitti <seismo!pur-ee!pucc-h!ach>
Subject: Re: standardized error messages
To: ecn.ARPA!cbosgd!seismo!ut-sally!std-unix

>From: Douglas Spencer <seismo!mcvax!daisy!maugg>
>> some commands take arguments as
>> command -abcdefg filename
>> and some as
>> command -a -b -c -d -e -f -g filename
>> It would be great if this was standardised.
	The result being getopt, based on these rules:
>   - Command names must be between 2 and 9 characters ("kermit" is 6).
>   - Command names must include lower case letters and digits only.
>   - An option name is a single character.
>   - Options are delimited by '-'.
>   - Options with  no  arguments  may  be  grouped  (bundled)  behind  one
>     delimiter.
>   - Option-arguments cannot be optional.
>   - Arguments immediately follow options, separated by whitespace.
>   - The order of options does not matter.
>   - '-' preceded and followed by whitespace means standard input.
>A group of bundled options may end with an option that has an argument.
	I prefer to make a forward sighted change, rather than a backwords
compatibility of the problem.  Going from no standard to a bad one is
no gain.  At least with no standard, people had the option of doing it
"right".  Once a standard is invented, it can't really be changed:
the only recourse is to reinvent a new universe.  Rules I use for
new programs are:
1)     Command names must be real words or concatenations of words,
	max 9 characters (for V7 systems, for now).  They must not be
	one letter.  They should be more than 4.  Abreviations for
	parts of the command are acceptible, such as "mk" for "make" and
	"ck" for "check".  Especially if a real word can be used - "mkdepend".
	Suffixes are better - "filesysck" (might be a better name for "fsck").
	Siffixes allow the same abbreviation, but allow someone to write a
	command-completion or least-ambiguous command recognition shell.
2)     Command names should be lower case.
3)     Option names are real words.  Single letters are too difficult
	to remember.  They are to be parsed in a least ambiguous fashion.
4)     "-help" IS an option.  This gives a usage message and a one-line
	description of each option.  The manual page should be nearly
	superflous.  In interactive mode "?" gives a quick list of command
	names.
5)     Options start with a "-", on the command line.
6)     Options with arguments are of the form -foo=bar,foobar.
7)     Options do not get bundled together.  This is bogus.
8)     Option-argumets are optional.  The default is useful.
9)     If no options are given, something reasonable will happen.  If
	nothing reasonable can be done, a usage message will be printed.
10)    Having an interactive mode is not an unreasonable thing for a
	program to have.  The interactive mode HAS a prompt (which may
	be turned off/changed).
11)    Non-options are usually file names.
12)    Options and file names may be interspersed.  The order of options
	often matters.  If this is the case, left to right parsing is used.
	So, if two options (such as -optimize and -nooptimize) conflict,
	the rightmost will be used.  Note that "pascal -opt file2 -noopt
	file3" will optimize file2, but not file3.

	To this end, I have written a least ambiguous command parser
subroutine library which can be used from the command line and/or
interactively.  It works well.  I like to have billions of options
in my programs, but can never remember them.  Some of them are seldom
used.  Often, new options are added.  Shell scripts won't break if they
always used the whole option name.  Shell scripts are more readable if
they use the whole option name.  Usually one need only type one
or two letters of an option name.
	There are some programs out there that do least ambiguous command
parsing:  "lpc", "ftp" and "kermit" are some.  There's a whole operating
system too: "twenex".
	The reason I vote for such change is that UNIX is no longer V6,
with 50 commands, each with 5 options.  It's now 400 commands, each with
10 options.  V6 ran on an 11/40 that had a single RK05 (2.5 Megabytes),
full sources, with 300+ blocks left for the user (150 K bytes of disk).
RK05's are now little bigger than floppys (and little faster).  Now
if you only have 100 Meg devoted to /usr, you might not be able to have
quite everything on it.  News or sources might have to be put elsewhere.
Certainly your users will be elsewhere.
	The systems are bigger, and harder to maintain.  That's progress.
	Steve Uitti, PUCC, ...pur-ee!pucc-h!ach (ach at purdue-asc.ARPA).

(The opions expressed...)

------------------------------

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:	ut-sally!std-unix	or std-unix at ut-sally.ARPA
Comments-To: ut-sally!std-unix-request	or std-unix-request at ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)