home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0032.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  7.9 KB
  1. From: John Quarterman (moderator) <std-unix-request@ut-sally>
  2. Topic: command line arguments (getopt)
  3.     Is the AT&T getopt public domain, or just published?
  4.     AT&T getopt(3) man page is inaccurate.
  5.     Inclusion of stdio and size of programs.
  6.     Options, white space, and shell scripts.
  7.     Full word command names and arguments, and completion.
  8.  
  9. ----------------------------------------------------------------------
  10.  
  11. From: ihnp4!utzoo!henry (Henry Spencer)
  12. Date: 19 Jul 85 20:14:44 CDT (Fri)
  13. To: ihnp4!seismo!ut-sally!std-unix
  14. Subject: Is AT&T getopt public-domain?  Not clear!
  15.  
  16. The document I have from the /usr/group standards meeting at Dallas
  17. does *not* say that the AT&T getopt is being made public domain.  What
  18. it says is:
  19.  
  20.     The [getopt] source code is being published by AT&T Bell
  21.     Laboratories to encourage adherence to the command syntax
  22.     standard and to satisfy requests from [everyone in sight].
  23.  
  24. Note that publishing something does *not* put it into the public domain
  25. unless this is stated explicitly.  That may have been AT&T's intent, but
  26. they didn't say it that way.  The document in question includes the AT&T
  27. source, but I am reluctant to submit it to mod.std.unix until its status
  28. is clarified.
  29.  
  30.                 Henry Spencer @ U of Toronto Zoology
  31.                 {allegra,ihnp4,linus,decvax}!utzoo!henry
  32.  
  33. ------------------------------
  34.  
  35. Date: 20 Jul 85 11:03:28 EDT (Sat)
  36. From: topaz!packard!nomad!ggr (Guy Riddle)
  37. Subject: getopt: the Code vs. the Manual Page
  38. To: ut-sally!std-unix
  39. Cc: seismo!keith
  40.  
  41. I hope you haven't been modelling the 4.3 version of getopt(3) too
  42. closely after the SVR2 manual page, for it lies about the details.
  43.  
  44. It states
  45.  
  46.     "Because optind is external, it is normally initialized to
  47.     zero automatically before the first call to getopt."
  48.  
  49. Well, I'll grant that optind is external, but it is initialized to one.
  50.  
  51. Also, the claim that
  52.  
  53.     "This error message may be disabled by setting opterr
  54.     to a non-zero value."
  55.  
  56. is also a lie.  Opterr is initialized to one, and to disable the error
  57. message you must set it to zero.
  58.  
  59.         === Guy Riddle == AT&T Bell Laboratories, New Jersey ===
  60.  
  61. ----------
  62. |Rebuttal
  63. |Corner
  64. |
  65.     Keith's assertion that
  66.  
  67.     > Not true.  The size difference between:
  68.     > 
  69.     >     main() { puts("foo"); }
  70.     > and
  71.     >     main() { write(0,"foo",3); }
  72.     > 
  73.     > is exactly zero.
  74.  
  75.     might be valid for 4.2, but it's not for SVR2, where the size of the
  76.     puts(3) version is
  77.  
  78.         2432 + 456 + 2232 = 5120
  79.  
  80.     while the write(2) version is only
  81.  
  82.         128 + 12 + 0 = 140
  83.  
  84. ------------------------------
  85.  
  86. From: ihnp4!decvax!borman (Dave Borman)
  87. Date: Sat, 20 Jul 85 21:01:42 edt
  88. To: decvax!ihnp4!ut-sally!std-unix
  89. Subject: getopt(3) & stdio
  90.  
  91. >  >  > Actually this is important in some applications which do not already use
  92. >  >  > stdio and do not wish to load in the 10k or so overhead that using stdio
  93. >  >  > incurs. AT&T's code does not use stdio in getopt(3).
  94. >  > 
  95. >  >  Not true.  The size difference between:
  96. >  > 
  97. >  >      main() { puts("foo"); }
  98. >  >  and
  99. >  >      main() { write(0,"foo",3); }
  100. >  > 
  101. >  >  is exactly zero.
  102. >  
  103. >  Your second one-liner is still using stdio.  The difference between
  104. >     main() { puts("foo"); }
  105. >  and
  106. >     main() { write(1, "foo", 3); }   exit(n) { _exit(n); }
  107. >  on the other hand, is substantial, at least on my 4.2 VAX system (and, in my
  108. >  experience, on other UNIX systems as well):
  109.  
  110. The first two examples are different, the puts() will pull in stdio and
  111. the write() should not.  If you have to explicitly re-declare exit() to
  112. avoid pulling in the stdio package, then your /lib/libc.a is mucked up.
  113. exit() calls _cleanup, of which there are two copies in the /lib/libc.a.
  114. The stdio package has a function _cleanup which flushes all the buffers.
  115. There is also a dummy _cleanup routine (usually fakcu.s) which just
  116. returns.  In /lib/libc.a, exit() must be archived after all the stdio
  117. functions, and the dummy _cleanup must be archived after exit.  If you
  118. have exit() before the stdio functions, then the reference to _cleanup
  119. will pull in the whole stdio package.  If exit() is after the stdio
  120. package and the dummy _cleanup after exit(), then if you don't reference
  121. any stdio functions you will only pull in the dummy cleanup routine.
  122.  
  123.         -Dave Borman, Digital UNIX Engineering Group.
  124.         decvax!borman
  125.  
  126. ------------------------------
  127.  
  128. Date: Sat, 20 Jul 85 16:31:33 PDT
  129. From: seismo!sun!guy (Guy Harris)
  130. To: ut-sally!jsq
  131. Subject: Re: a bit more on getopt
  132.  
  133. > Not true.  The size difference between:
  134. >
  135. >    main() { puts("foo"); }
  136. > and
  137. >    main() { write(0,"foo",3); }
  138. >
  139. > is exactly zero.
  140.  
  141. Only true on certain UNIX implementations.  Under Sun UNIX 2.0
  142. (4.2BSD-based), there is a slight difference.  Under System V there is a
  143. significant difference.  The problem is that 4.2BSD *always* drags in the
  144. Standard I/O Library while System V doesn't.  4.xBSD could be changed, with
  145. about 30 minutes work, to work the way System V does here, so the assumption
  146. should be made that the Standard I/O Library does consume a nonzero amount
  147. of code and data space.  (About 13788 bytes in one test I did; this doesn't
  148. count buffers which are "malloc"ed when the first read/write is done.)
  149.  
  150.     Guy Harris
  151.  
  152. ------------------------------
  153.  
  154. From: ihnp4!utzoo!henry (Henry Spencer)
  155. Date: 20 Jul 85 20:45:50 CDT (Sat)
  156. To: ihnp4!seismo!ut-sally!std-unix
  157. Subject: Re: a bit more on getopt
  158. References: <251@mcc-db.UUCP> <2365@ut-sally.UUCP> <2392@ut-sally.UUCP>, <2399@ut-sally.UUCP>
  159.  
  160. > > ...  The "-t/dev/tty" example is an easy one
  161. > > to pick out, but what about "-dfaglop"?  Which of those letters are
  162. > > options, and which are an option argument?
  163. > 
  164. > OK, instead of forcing whitespace, how about requiring that there only be one
  165. > flag if you are going to do this sort of stuff? I have had shell scripts
  166. > totally broken by this requirement, and workarounds take up so much overhead
  167. > (yes, some people have systems smaller than vaxen) that it's not worth the
  168. > hassle.
  169.  
  170. We do a *lot* of shell programming, and our experience is that the
  171. separating blank makes life easier, not harder.  Of course, we generally
  172. use getopt(1) for the argument parsing, which makes life simpler.  utzoo
  173. is a PDP11, by the way.
  174.  
  175.                 Henry Spencer @ U of Toronto Zoology
  176.                 {allegra,ihnp4,linus,decvax}!utzoo!henry
  177.  
  178. ------------------------------
  179.  
  180. From: ihnp4!utzoo!henry (Henry Spencer)
  181. Date: 19 Jul 85 20:15:23 CDT (Fri)
  182. To: ihnp4!seismo!ut-sally!std-unix
  183. Subject: Command lines
  184.  
  185. > It's probably way too late for this to be suggested, but the longer it's
  186. > left, the worse it will be.
  187. > How about completely revamping the unix command line syntax to be
  188. >     command {{-option ...} {file ...} ...}
  189. > with command names & option names being full words (e.g. remove, not rm)...
  190.  
  191. The AT&T command-line-syntax people have alluded to attempts to do this
  192. in the past at AT&T.  They were failures.  It is not enough to decree a
  193. standard; one must also convince people to accept it.  The getopt standard
  194. has been widely accepted precisely *because* it tidies up and standardizes
  195. the existing situation, rather than trying to impose radical change.
  196.  
  197. There are also problems with full-word options, and worse problems with
  198. full-word options that can be arbitrarily abbreviated, but I won't get
  199. into that since it seems a digression.
  200.  
  201. I've thought about this at considerable length, and concluded that radical
  202. change will require more incentive than a simplistic revision of command
  203. syntax would provide.  VMS-style "completion" isn't enough.  What one wants
  204. is much more sophisticated help in command construction, including things
  205. like interactive "help" information for options, knowledge of the semantics
  206. of arguments so that error repair can be applied, etc.  Imbedding this into
  207. every program seems dubious; it would seem better to have a sophisticated
  208. shell which uses a database describing the commands.  Note that such an
  209. interface could completely hide the details of the *actual* command syntax.
  210. Someday...
  211.                 Henry Spencer @ U of Toronto Zoology
  212.                 {allegra,ihnp4,linus,decvax}!utzoo!henry
  213.  
  214. ------------------------------
  215.  
  216. Volume-Number: Volume 1, Number 33
  217.  
  218.