home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0050.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  5.4 KB
  1. From: John Quarterman (moderator) <std-unix-request@ut-sally>
  2. Topic: standardized error messages
  3.  
  4. The idea proposed in this message has been proposed before in this newsgroup.
  5. I am letting it through anyway, since this is a more complete description
  6. of the idea.  After the flurry of rebuttals which will no doubt ensue,
  7. I would prefer we not rehash it yet a third time.
  8.  
  9. If the discussion devolves into a TOPS-20 vs. UNIX flaming match, I will
  10. at some point (soon) arbitrarily cut it off.
  11.  
  12. ----------------------------------------------------------------------
  13.  
  14. Date: Fri, 5 Jul 85 12:25:33 est
  15. From: Stephen Uitti <seismo!pur-ee!pucc-h!ach>
  16. Subject: Re: standardized error messages
  17. To: ecn.ARPA!cbosgd!seismo!ut-sally!std-unix
  18.  
  19. >From: Douglas Spencer <seismo!mcvax!daisy!maugg>
  20. >> some commands take arguments as
  21. >> command -abcdefg filename
  22. >> and some as
  23. >> command -a -b -c -d -e -f -g filename
  24. >> It would be great if this was standardised.
  25.     The result being getopt, based on these rules:
  26. >   - Command names must be between 2 and 9 characters ("kermit" is 6).
  27. >   - Command names must include lower case letters and digits only.
  28. >   - An option name is a single character.
  29. >   - Options are delimited by '-'.
  30. >   - Options with  no  arguments  may  be  grouped  (bundled)  behind  one
  31. >     delimiter.
  32. >   - Option-arguments cannot be optional.
  33. >   - Arguments immediately follow options, separated by whitespace.
  34. >   - The order of options does not matter.
  35. >   - '-' preceded and followed by whitespace means standard input.
  36. >A group of bundled options may end with an option that has an argument.
  37.     I prefer to make a forward sighted change, rather than a backwords
  38. compatibility of the problem.  Going from no standard to a bad one is
  39. no gain.  At least with no standard, people had the option of doing it
  40. "right".  Once a standard is invented, it can't really be changed:
  41. the only recourse is to reinvent a new universe.  Rules I use for
  42. new programs are:
  43. 1)     Command names must be real words or concatenations of words,
  44.     max 9 characters (for V7 systems, for now).  They must not be
  45.     one letter.  They should be more than 4.  Abreviations for
  46.     parts of the command are acceptible, such as "mk" for "make" and
  47.     "ck" for "check".  Especially if a real word can be used - "mkdepend".
  48.     Suffixes are better - "filesysck" (might be a better name for "fsck").
  49.     Siffixes allow the same abbreviation, but allow someone to write a
  50.     command-completion or least-ambiguous command recognition shell.
  51. 2)     Command names should be lower case.
  52. 3)     Option names are real words.  Single letters are too difficult
  53.     to remember.  They are to be parsed in a least ambiguous fashion.
  54. 4)     "-help" IS an option.  This gives a usage message and a one-line
  55.     description of each option.  The manual page should be nearly
  56.     superflous.  In interactive mode "?" gives a quick list of command
  57.     names.
  58. 5)     Options start with a "-", on the command line.
  59. 6)     Options with arguments are of the form -foo=bar,foobar.
  60. 7)     Options do not get bundled together.  This is bogus.
  61. 8)     Option-argumets are optional.  The default is useful.
  62. 9)     If no options are given, something reasonable will happen.  If
  63.     nothing reasonable can be done, a usage message will be printed.
  64. 10)    Having an interactive mode is not an unreasonable thing for a
  65.     program to have.  The interactive mode HAS a prompt (which may
  66.     be turned off/changed).
  67. 11)    Non-options are usually file names.
  68. 12)    Options and file names may be interspersed.  The order of options
  69.     often matters.  If this is the case, left to right parsing is used.
  70.     So, if two options (such as -optimize and -nooptimize) conflict,
  71.     the rightmost will be used.  Note that "pascal -opt file2 -noopt
  72.     file3" will optimize file2, but not file3.
  73.  
  74.     To this end, I have written a least ambiguous command parser
  75. subroutine library which can be used from the command line and/or
  76. interactively.  It works well.  I like to have billions of options
  77. in my programs, but can never remember them.  Some of them are seldom
  78. used.  Often, new options are added.  Shell scripts won't break if they
  79. always used the whole option name.  Shell scripts are more readable if
  80. they use the whole option name.  Usually one need only type one
  81. or two letters of an option name.
  82.     There are some programs out there that do least ambiguous command
  83. parsing:  "lpc", "ftp" and "kermit" are some.  There's a whole operating
  84. system too: "twenex".
  85.     The reason I vote for such change is that UNIX is no longer V6,
  86. with 50 commands, each with 5 options.  It's now 400 commands, each with
  87. 10 options.  V6 ran on an 11/40 that had a single RK05 (2.5 Megabytes),
  88. full sources, with 300+ blocks left for the user (150 K bytes of disk).
  89. RK05's are now little bigger than floppys (and little faster).  Now
  90. if you only have 100 Meg devoted to /usr, you might not be able to have
  91. quite everything on it.  News or sources might have to be put elsewhere.
  92. Certainly your users will be elsewhere.
  93.     The systems are bigger, and harder to maintain.  That's progress.
  94.     Steve Uitti, PUCC, ...pur-ee!pucc-h!ach (ach@purdue-asc.ARPA).
  95.  
  96. (The opions expressed...)
  97.  
  98. ------------------------------
  99.  
  100. Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
  101. Submissions-To:    ut-sally!std-unix    or std-unix@ut-sally.ARPA
  102. Comments-To: ut-sally!std-unix-request    or std-unix-request@ut-sally.ARPA
  103. UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
  104. Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
  105.  
  106. Volume-Number: Volume 1, Number 51
  107.  
  108.