home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0023.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  4.8 KB
  1. From: John Quarterman <std-unix-request@ut-sally.UUCP> (moderator)
  2. Topic: command line arguments (getopt)
  3.  
  4. There's getting to be a bit of repetition and a certain amount of
  5. flamage on this subject.  Several things seem clear to me, at least:
  6.  
  7. 1) Keith Bostic's getopt is the de facto standard public domain getopt
  8.     because a) it implements everything the System V one does,
  9.     down to specific error messages and global variables, and
  10.     b) it's going to be in 4.3BSD.  It also may or may not be
  11.     more efficient or smaller when seen in perspective.
  12. 2) Henry Spencer's getopt, in the version that I posted that Ian Darwin
  13.     sent, is just about as good, since its earlier bug is fixed,
  14.     though it lacks some undocumented System V features which
  15.     Bostic's includes.
  16. 3) There are numerous minor functional changes which might be desirable
  17.     for one reason or another, but they would *be* changes, and are
  18.     not in the "standard" getopt.  The existing getopt is good
  19.     enough for most purposes, and is widely available:  there is
  20.     no need for another implementation.
  21.  
  22. While these are my personal opinions, they appear to agree with
  23. those of the two getopt authors mentioned above.  Since I have
  24. to go by something in moderating the newsgroup, I will discourage
  25. from now on submissions which merely argue the above points again.
  26. In other words, let's try to think of something new to say, or
  27. go on to something else.
  28.  
  29.  
  30. ----------------------------------------------------------------------
  31.  
  32. From: ihnp4!utzoo!henry (Henry Spencer)
  33. Date: 15 Jul 85 16:10:12 CDT (Mon)
  34. To: ihnp4!ut-sally!std-unix
  35. Subject: Re: What to do about extraneous arguments?
  36. References: <251@mcc-db.UUCP>
  37.  
  38. > Common practice seems to be to ignore extraneous arguments.  A user here
  39. > has requested that cmp(1) be modified to generate a diagnostic if more
  40. > than 2 filenames are provided.  ...
  41.  
  42. The standard program skeleton for using getopt(3) includes, after the
  43. big while-switch for the options, the code:
  44.  
  45.     if (errflg) {
  46.         fprintf(stderr, "Usage: ...\n");
  47.         exit(2);
  48.     }
  49.  
  50. It's pretty simple to change that "if (errflg) {" to something like
  51. "if (errflg || optind+2 != argc) {".  This is what we do in such cases.
  52. Easy and effective.
  53.                 Henry Spencer @ U of Toronto Zoology
  54.                 {allegra,ihnp4,linus,decvax}!utzoo!henry
  55.  
  56. ------------------------------
  57.  
  58. From: ihnp4!utzoo!henry (Henry Spencer)
  59. Date: 15 Jul 85 16:09:35 CDT (Mon)
  60. To: ihnp4!ut-sally!std-unix
  61. Subject: Re: command line arguments
  62. References: <2210@ut-sally.UUCP>, <244@mcc-db.UUCP>
  63.  
  64. > Regarding getopts and the 'all arguments are proceded by a "-"':
  65. > What about arguments that can be on/off switches, or can be positive or
  66. > negative numbers? In other words, what is wrong with allowing '+' as an
  67. > indicator of arguments? There are some commands that use it already.
  68.  
  69. The AT&T people considered this.  (It would be nice to see a posting of
  70. the AT&T paper, in fact, if someone has it machine-readable [I don't]
  71. [ I don't either, but if someone would mail it to me, I would post it
  72. (if it's reasonably short) -mod ]; it would shorten this discussion
  73. considerably.)  They thought the following were reasonable criteria for
  74. accepting + :
  75.  
  76. 1. Clear, simple, well-defined rules for when + should be used.
  77. 2. Rules should be applicable to more than just a few atypical commands.
  78. 3. Use of + should complement, not conflict with, the general use of -
  79.     as an option marker (*not* as a "negation" indicator, note).
  80.  
  81. Their observations were that the existing uses of + meet none of these
  82. criteria, that compatibility would prevent cleaning up existing uses,
  83. and that criterion #3 seemed impossible to satisfy.  So, no +.
  84.  
  85. > Incidently, what happens with getopts if the command line was
  86. > command -n -30
  87. > and:
  88. > Option n is fetched
  89. > option 3 is fetched
  90. > option 0 is fetched
  91. > 
  92. > (No well written program would do all this, but essentially, what happens
  93. > if an argument looks like a flag? Or have you never grep'ed for a string
  94. > beginning with -?)
  95.  
  96. If -n is an option taking a value, then the next argument is its value,
  97. even if it happens to have a - on the front.  The apparent ambiguity is
  98. resolved by knowing which options take values and which don't.
  99.  
  100.                 Henry Spencer @ U of Toronto Zoology
  101.                 {allegra,ihnp4,linus,decvax}!utzoo!henry
  102.  
  103. ----------------------------------------------------------------------
  104.  
  105. The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
  106. in particular of the draft standard in progress by the IEEE P1003
  107. "UNIX Standards" Committee.
  108.  
  109. Submissions to the newsgroup to:    ut-sally!std-unix
  110. Comments about the newsgroup to:    ut-sally!std-unix-request
  111. Permission to post to the newsgroup is assumed for mail to the former address,
  112. but not for mail to the latter address, nor for mail to my personal addresses.
  113. -- 
  114.  
  115. John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
  116. ARPA Internet and CSNET:  jsq@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDU
  117.  
  118. Volume-Number: Volume 1, Number 24
  119.  
  120.