Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!decvax!genrad!panda!talcott!harvard!seismo!ut-sally!jsq From: jsq@ut-sally.UUCP (John Quarterman) Newsgroups: mod.std.unix Subject: Re: standardized error messages Message-ID: <2607@ut-sally.UUCP> Date: Tue, 6-Aug-85 18:41:02 EDT Article-I.D.: ut-sally.2607 Posted: Tue Aug 6 18:41:02 1985 Date-Received: Wed, 7-Aug-85 08:57:24 EDT References: <2391@ut-sally.UUCP> <2461@ut-sally.UUCP> <2474@ut-sally.UUCP> <2560@ut-sally.UUCP> <2597@ut-sally.UUCP> Reply-To: std-unix@ut-sally.UUCP Organization: U. Texas CS Dept., Austin, Texas Lines: 104 Approved: jsq@ut-sally.UUCP Summary: UNIX as TOPS-20 From: John Quarterman (moderator)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 Subject: Re: standardized error messages To: ecn.ARPA!cbosgd!seismo!ut-sally!std-unix >From: Douglas Spencer >> 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@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@ut-sally.ARPA Comments-To: ut-sally!std-unix-request or std-unix-request@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)