home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0002.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  9.9 KB  |  233 lines
  1. [ I've picked this up from net.unix.  It explains what the rules 5 and 6 are,
  2. regarding getopt(3).  -mod ]
  3.  
  4. >From: perlman@wanginst.UUCP (Gary Perlman)
  5. Date: 30 Oct 85 18:03:01 GMT
  6.  
  7. I tried to post this to mod.std.unix, but it got bounced by the mailer.  Sigh.
  8. ------------------
  9.  
  10.                  Proposed Syntax Standard
  11.                  For UNIX* System Commands
  12.  
  13. RULE  1:  Command names must be between 2 and 9 characters.
  14.  
  15. RULE  2:  Command names must include lower case letters and
  16.           digits only.
  17.  
  18. RULE  3:  Option names must be a single character in length.
  19.  
  20. RULE  4:  All options must be delimited by ``-''.
  21.  
  22. RULE  5:  Options with no arguments may be grouped behind
  23.           one delimiter.
  24.  
  25. RULE  6:  The first option-argument following an option
  26.           must be preceded by white space.
  27.  
  28. RULE  7:  Option arguments cannot be optional.
  29.  
  30. RULE  8:  Groups of option-arguments following an option must be
  31.           separated by commas or separated by white space and quoted.
  32.  
  33. RULE  9:  All options precede operands on the command line.
  34.  
  35. RULE 10:  ``--'' may be used to delimit the end of the options.
  36.  
  37. RULE 11:  The order of options relative to one another
  38.           should not matter.
  39.  
  40. RULE 12:  The order of operands may matter and position-related
  41.           interpretations should be determined on a
  42.           command-specific basis.
  43.  
  44. RULE 13:  ``-'' preceded and followed by white space should be used
  45.           only to mean the standard input.
  46.  
  47.                                                   November 1983
  48. *UNIX is a trademark of AT&T Bell Laboratories
  49.  
  50. --------------------------------------------------------------------
  51.  
  52. The above  is a  direct quote  of the  quick reference  card
  53. handed out in  conjunction with  a talk at  the 1984  Winter
  54. Usenix conference by K. Hemenway & H. Armitage.  This set of
  55. rules is sometimes called the H&A standard.  Any proposal of
  56. a standard is  going to  cause controversy, and  this is  no
  57. exception.  Although I at first was opposed to the standard,
  58. I came to appreciate the thought that went into it.  In this
  59. commentary, I hope to convey that to you.
  60.  
  61. General comments: The H&A standard tries to maintain as much
  62. compatibility with  existing  programs while  improving  the
  63. consistency of  UNIX  command line  syntax.   This  is  much
  64. harder than designing  a command line  syntax from  scratch.
  65. It is important to understand the rationale behind the whole
  66. set of  conventions  before  making  judgements  about  them
  67. individually.
  68.  
  69. H&A recorded the  syntax for  all the commands  in UNIX  (at
  70. least System V UNIX).  They tried to come up with a standard
  71. that was  as  close to  most  of the  existing  commands  as
  72. possible.  Their analysis, summarized in their USENIX paper,
  73. but much better covered in an unavailable internal Bell Labs
  74. tech report, is an  excellent example of backing  statements
  75. with facts.  The most common example of an objection to  the
  76. standard is of the  form, "I don't like  RULE X. What  about
  77. the zz command?"  to which  H&A could  say, "That  exception
  78. happens in  only N  (few) commands."  Here are  my  comments
  79. about the rules.  They contain my reaction to the rules  and
  80. some of H&A's reasons for the rules.
  81.  
  82. I want to start by saying that this standard is much  better
  83. than no standard.   If  I know  that a  command follows  the
  84. standard, then there are no surprises about how options  are
  85. requested and that makes life easier  for me.  I don't  have
  86. to  worry  about  inconsistency,  and  that  overwhelms  the
  87. quirks of the standard.
  88.  
  89. RULE 1:
  90.           I see no reason for not allowing single  character
  91.           command names like e, f,  w, and S, but there  are
  92.           not many of  these.   There is  not much  mnemonic
  93.           value to  single  character commands,  nor  for  2
  94.           character commands, but there are a lot of those.
  95.  
  96. RULE 2:
  97.           The restriction to lower case letters only is  for
  98.           case insensitive systems.   One notable  exception
  99.           is a.out, but that is  not really a command  name.
  100.           Not allowing  special characters  like  underscore
  101.           simplifies the rules.
  102.  
  103. RULE 3:
  104.           Single  character  option   names  are  not   very
  105.           mnemonic, but  they are  necessary to  be able  to
  106.           bundle options.  They are also used in most of the
  107.           commands.     Their   lack   of   mnemonicity   is
  108.           compensated somewhat when on-line help is  readily
  109.           available, which unfortunately is not common.
  110.  
  111. RULE 4:
  112.           The convention of preceding options with - started
  113.           to distinguish  options  from file  names.    Some
  114.           commands that do not  take operands like files  or
  115.           expressions  do  not  require  the  -  sign.    My
  116.           experience is  that  this  is  an  extra  rule  to
  117.           explain to new  users that is  not worth saving  a
  118.           keystroke here and there.
  119.  
  120. RULE 5:
  121.           Bundling of options  was a rule  demanded by  UNIX
  122.           fans inside Bell Labs.  Once you accept this rule,
  123.           you can't  have  multiple character  options,  and
  124.           this is unfortunate.  Still,  I would not like  to
  125.           have to type: ls -l -t -r.
  126.  
  127. RULE 6:
  128.           Many programs  require  that  an  option  argument
  129.           immediately follow the option (e.g., cc -lm, nroff
  130.           -man) while  some require  a  space (e.g.,  cc  -o
  131.           pgm).  This is  one inconsistency that causes  the
  132.           most problems  for me, especially when  there  are
  133.           inconsistencies inside a command  (cf.  cc,  which
  134.           passes the  tightly  grouped  option-arguments  to
  135.           other  programs).     Rather   than  deciding   on
  136.           no-space, a space is required in the H&A standard.
  137.           This is to make sure that filename expansion works
  138.           properly.   For example,  if  the argument  to  an
  139.           option is a  file like  "extralongname", then  the
  140.           option -fextra*  would not  work, while  having  a
  141.           space in there would.   You could make the  syntax
  142.           "space-optional" but that  would require that  the
  143.           documentation cover more  than one  case, which  I
  144.           argue would make the syntax harder to learn.
  145.  
  146. RULE 7:
  147.           Because option  arguments must  be separated  from
  148.           options,  there  is  no  way  to  make  an  option
  149.           argument optional, except for the special case  of
  150.           at the end of a command line with no operands (but
  151.           I think  this  rare  exception would  be  hard  to
  152.           explain).   There  are  few  commands  that  allow
  153.           optional  option-arguments  (e.g.,  pr  -h),   and
  154.           supplying a  null argument  (ie.   "")  works  are
  155.           well.
  156.  
  157. RULE 8:
  158.           This rule does not allow for syntax like:
  159.               pgm -i file1 file2 file3 -o file4 file5
  160.           but this  is  not  very common.    Placing  quotes
  161.           around the files is not too bad.
  162.  
  163. RULE 9:
  164.           When options must  precede operands (e.g.,  files)
  165.           several practices  are  not  supported.    One  is
  166.           choosing a set  of options for  one file and  then
  167.           some options for another.  Instead of this, two or
  168.           more command lines are needed,  but this is not  a
  169.           serious penalty  for  most  commands,  and  not  a
  170.           common need.  The  second unsupported practice  is
  171.           that of thinking of  options after typing most  of
  172.           the  command   line;  if   options  must   precede
  173.           operands, then they must be inserted.  While  this
  174.           can be awkward  for some primitive  shells, it  is
  175.           best handled with  command line  editing, such  as
  176.           that in ksh.
  177.  
  178. RULE 10:
  179.           You really need -- to  delimit the end of  options
  180.           so that files or expressions that begin with - can
  181.           be processed.  The string  -- was used because  of
  182.           getopt's use.   This is not  a strong  motivation,
  183.           because at the time of the standard, only about 40
  184.           commands used getopt.  Still,  it seems as good  a
  185.           delimiter as any.
  186.  
  187.  
  188. RULE 11:
  189.           I do not know why the order of options should  not
  190.           matter.  It does matter  in commands like cc  (ie.
  191.           ld) that requires a special ordering to libraries.
  192.  
  193. RULE 12:
  194.           This rule says that the programmer can choose  any
  195.           meaning to what follows the options.  Makes  sense
  196.           to me.
  197.  
  198. RULE 13:
  199.           There is some tradition and a definite need to  be
  200.           able to insert the standard  input into a list  of
  201.           files.  The - has been used in a few commands, and
  202.           there were no likely contenders.
  203.  
  204. My impression is that  the H&A standard is  one we can  live
  205. with.   It is  not the  sort of  syntax that  someone  might
  206. design from scratch, but there  is a need for  compatibility
  207. with old  syntax, not  just for  user comfort,  but also  to
  208. avoid breaking  thousands  of shell  scripts  and  system(3)
  209. calls to UNIX command lines.  Yes, there is some more typing
  210. required, but I think it  is not a high  price to pay for  a
  211. set of conventions you can fit on a small card.  To get  all
  212. the  time-savers  we  like,   the  syntax  gets  much   more
  213. complicated, which  I  think  is  one  reason  for  the  bad
  214. reputation UNIX has earned.
  215.  
  216. What about existing commands?  Last I heard, the plan was to
  217. first work on the  easy cases, the  commands that were  very
  218. close to the standard.   Some commands would not be  changed
  219. but be replaced  by new  programs that would  phase out  the
  220. old.   Some  examples of commands  with extremely  difficult
  221. syntax are "pr" and "sort".  The "test" command is  finessed
  222. by saying  that  it does  not  use options,  but  a  special
  223. expression language.  The "find" command could be dealt with
  224. similarly.    The  "dd"  command,  with  name-value   format
  225. options, originally  designed as  a parody  of the  IBM  DD,
  226. would not change.
  227. -- 
  228. Gary Perlman  Wang Institute  Tyngsboro, MA 01879  (617) 649-9731
  229. UUCP: decvax!wanginst!perlman             CSNET: perlman@wanginst
  230.  
  231. Volume-Number: Volume 3, Number 3
  232.  
  233.