home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.18 / text0003.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  9.5 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                             December 1989
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.2: Shell and tools Update
  13.  
  14. Randall Howard <rand@mks.com> reports on the October 16-20, 1989
  15. meeting in Brussels, Belgium:
  16.  
  17. Background on POSIX.2
  18.  
  19. The POSIX.2 standard deals with the shell programming language and
  20. utilities.  Currently, it is divided into two pieces:
  21.  
  22.    + POSIX.2, the base standard, deals with the basic shell
  23.      programming language and a set of utilities required for
  24.      application portability.  Application portability essentially
  25.      means portability of shell scripts and thus excludes most
  26.      features that might be considered interactive.  In an analogy to
  27.      the ANSI C standard, the POSIX.2 shell command language is the
  28.      counterpart of the C programming language, while the utilities
  29.      play, roughly, the role of the C library.  POSIX.2 also
  30.      standardizes command-line and function interfaces related to
  31.      certain POSIX.2 utilities (e.g., popen, regular expressions,
  32.      etc.) [Editor's note - This document is also known as "Dot 2
  33.      Classic".]
  34.  
  35.    + POSIX.2a, the User Portability Extension or UPE, is a supplement
  36.      to the base POSIX.2 standard; it will eventually be an optional
  37.      chapter of a future draft of the base document.  The UPE
  38.      standardizes commands, such as screen editors, that might not
  39.      appear in shell scripts but are important enough that users must
  40.      learn them on any real system.  It is essentially an interactive
  41.      standard that attempts to reduce retraining costs incurred by
  42.      system-to-system variation.
  43.  
  44.      Some utilities, have interactive as well as non-interactive
  45.      features In such cases, the UPE defines extensions from the base
  46.      POSIX.2 command.  An example is the shell, for which the UPE
  47.      defines job control, history, and aliases.  Features used both
  48.      interactively and in scripts tend to be defined in the base
  49.  
  50. __________
  51.  
  52.   * UNIX is a registered trademark of AT&T in the U.S. and other
  53.     countries.
  54.  
  55. December 1989 Standards Update            IEEE 1003.2: Shell and tools
  56.  
  57.  
  58.                                 - 2 -
  59.  
  60.      standard.
  61.  
  62. In my opinion, the biggest current problem with the UPE is that it
  63. lacks a coherent view: it's becoming a repository for features that
  64. didn't make it into the base standard.  For example, compress is in
  65. the current UPE draft.  It's hard to rationalize classifying file
  66. formats as an "interactive" or "user portability" issue, yet the one
  67. used by compress is specified in the UPE.  It certainly doesn't fit in
  68. with a view of the UPE as a standard that merely adds utility syntax
  69. information (e.g., information that would allow users to type the same
  70. command line to compress a file on any system).  This highlights the
  71. schizophrenic nature of the UPE: it addresses a range of different
  72. needs that, taken together, do not appear to define a whole.  Dot 2
  73. Classic, to my taste, appears to have far more unified scope and
  74. execution.
  75.  
  76. A second, related, problem with the UPE is that there appears to be
  77. less enthusiasm for it than for the base standard.  A number of
  78. people, including me, understand the need for it, but it doesn't
  79. appear to have the strategic importance of the base.  [Editor's note -
  80. The UPE is, frankly, controversial.  Like 1201, the committee
  81. undertook the UPE out of a fear that if they didn't, NIST would do the
  82. job without them.  Supporters note that although its utilities are
  83. probably not necessary for portability of most software, it would be
  84. unpleasant for programmers to do the porting work without them.
  85. Detractors counter that POSIX was never intended to cover software
  86. development and that the group is exceeding not only its charter, but
  87. that of the entire 1003 committee.]
  88.  
  89. Status of POSIX.2 Balloting
  90.  
  91. POSIX.2 is in its second round of balloting.  The first ballot, on
  92. Draft 8, produced many objections that are only partially resolved by
  93. Draft 9.  Although there were only fifty-four pages of unresolved
  94. objections remaining after Draft 9 was produced, the current balloting
  95. round is not restricted to existing objections, and there will almost
  96. certainly be many new ones.  Remaining objections range from the
  97. perennial war between David Korn and the UNIX Support Group over what
  98. features should be required in the POSIX shell, through the resolution
  99. of the incompatible versions (Berkeley and USG) of echo, to the
  100. treatment of octal and symbolic modes in umask.
  101.  
  102. A digression to illustrate the kind of issues being addressed:
  103.  
  104.      In March of 1989, a study group from 1003.2 met at AT&T to
  105.      resolve major objections to the shell specified in Draft 8 by the
  106.      two warring parties.  This was a good place to hold the meeting,
  107.      since both parties are from AT&T: one led by David Korn of Bell
  108.      Labs, the author of the popular Korn Shell (KSH) the other, a
  109.      group led by Rob Pike of Bell Labs Research and the UNIX Support
  110.      Organization, advocating more traditional shells, like the System
  111.  
  112. December 1989 Standards Update            IEEE 1003.2: Shell and tools
  113.  
  114.  
  115.                                 - 3 -
  116.  
  117.      V Bourne Shell and the Version 9 Research shell.  Korn's group
  118.      contends that the shell should be augmented to make it possible
  119.      to efficiently implement large scripts totally within the shell
  120.      language.  For example, while the more traditional camp views
  121.      shell functions as little more than command-level macros and uses
  122.      multiple scripts to modularize large shell applications, the Korn
  123.      shell views functions as a tool for modularizing applications,
  124.      and provides scoping rules to encourage this practice.
  125.  
  126.      The two philosophies engender different opinions on issues such
  127.      as the scoping of traps within functions and the use of local
  128.      variables.  Other contentious issues were the reservation of the
  129.      brace ({ }) characters as operators (rather than as the more
  130.      tricky "reserved words"), the promotion of tilde expansion to a
  131.      runtime expansion (like parameter expansion), and the issue of
  132.      escape sequences within echo/print/printf.
  133.  
  134.      The meeting produced a false truce.  I attended, and believe that
  135.      both parties had different views of the agreement that came out
  136.      of the meeting.  As a result, Draft 9 produced balloting
  137.      objections from both parties and the dispute continues unabated.
  138.      Shades of POSIX.1 Tar Wars...
  139.  
  140. I suspect the next draft (Draft 10) will fail to achieve the consensus
  141. required for a full-use standard.
  142.  
  143. This is a good thing.  Useful features are still finding their way
  144. into the document.  (Draft 9 introduces hexdump, locale, localedef,
  145. and more.) Also, the sheer size (almost 800 pages) of Draft 9 has
  146. prevented many balloters from thoroughly reviewing the entire
  147. document, Still, there is a stable core of utilities that is unlikely
  148. to change much more than editorially; I predict the standard will
  149. become final around Draft 12.
  150.  
  151. A mock ballot on Draft 4 of the UPE will probably start after the New
  152. Orleans meeting in January, and the resulting Draft 5 will probably go
  153. to a real ballot somewhere in summer to early fall of 1990.  Although
  154. many sections remain unwritten or unreviewed, the UPE is a much
  155. smaller standard than POSIX.2 and should achieve consensus more
  156. quickly.
  157.  
  158. Status of the Brussels Meeting
  159.  
  160. The Brussels meeting focused on the UPE, with only a summary report on
  161. the status of balloting for the base standard.  For most of the
  162. meeting, small groups reviewed and composed UPE utility descriptions.
  163. The changes generated at the meeting will appear in Draft 3.
  164.  
  165. The groups reviewed many utilities.  The chapter on modifications to
  166. the shell language (for interactive features) is now filled in, and
  167. such utilities as lint89 (the recently renamed version of lint), more,
  168.  
  169. December 1989 Standards Update            IEEE 1003.2: Shell and tools
  170.  
  171.  
  172.                                 - 4 -
  173.  
  174. etc.  are approaching completion.  Still, much work remains.
  175.  
  176. [Editor's complaint - We think renaming common commands like lint
  177. ("lint89") and cc ("c89") is both cruel and unusual.  We are not eager
  178. to re-write every makefile and shell script that refers to cc or lint,
  179. nor to re-train our fingers to find new keys each time the C compiler
  180. changes.  The name seems to have been coined by either a hunt-and-peck
  181. typist, or someone who has longer and more accurate fingers than we
  182. do.  (Was it, perhaps, the work of Stu Feldman, author of f77?)
  183. Moreover, replacing commands with newer versions is commonplace and
  184. traditional in UNIX.  Examples like "make", "troff", and "awk" spring
  185. to mind.  If an older version is kept on for die-hards, it's renamed
  186. (e.g., otroff, oawk).
  187.  
  188. One Dot-Two member rebuffed our objections with the reply, "But, you
  189. see, this isn't UNIX: it's POSIX." ]
  190.  
  191. Because the meeting was in Europe, attendance at the working group
  192. meetings was lower than normal (20-25 rather than the normal 35-40 in
  193. POSIX.2.  Nevertheless, the choice of location served a purpose.  The
  194. meeting was held in Brussels to garner international support and
  195. participation, particularly from the European Economic Community.
  196. There were many EEC representatives at the background sessions on
  197. POSIX and two or three European working group members in the POSIX.2
  198. meetings who wouldn't normally have attended.  Though it remains to be
  199. seen what will come out of having met in Brussels, I am convinced that
  200. the extra effort will prove to have been justified.
  201.  
  202. December 1989 Standards Update            IEEE 1003.2: Shell and tools
  203.  
  204.  
  205. Volume-Number: Volume 18, Number 4
  206.  
  207.