home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0050.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  8.8 KB
  1. From: <jsh@usenix.org>
  2.  
  3.             An Update on UNIX* and C Standards Activities
  4.  
  5.                              January 1990
  6.  
  7.                  USENIX Standards Watchdog Committee
  8.  
  9.                    Jeffrey S. Haemer, Report Editor
  10.  
  11. IEEE 1003.2: Shell and tools Update
  12.  
  13. Randall Howard <rand@mks.com> reports on the January 8-12, 1990
  14. meeting in New Orleans, LA:
  15.  
  16. Background on POSIX.2
  17.  
  18. The POSIX.2 standard deals with the shell programming language and
  19. utilities.  Currently, it is divided into two pieces:
  20.  
  21.    + POSIX.2, the base standard, deals with the basic shell
  22.      programming language and a set of utilities required for
  23.      application portability.  ``Application portability'' essentially
  24.      means portability of shell scripts and excludes most interactive
  25.      features.  In an analogy to the ANSI C standard, the POSIX.2
  26.      shell command language is the counterpart of the C programming
  27.      language, while the utilities play, roughly, the role of the C
  28.      library.  POSIX.2 also standardizes command-line and function
  29.      interfaces of some POSIX.2 utilities (e.g., popen(), regular
  30.      expressions, etc.) This document is also known as ``Dot 2
  31.      Classic.''
  32.  
  33.    + POSIX.2a, the User Portability Extension or UPE, supplements the
  34.      base POSIX.2 standard; it will become a non-normative (optional)
  35.      chapter of some future draft of the base document.  The UPE
  36.      standardizes commands, such as screen editors, that might not
  37.      appear in shell scripts but that users must learn on any real
  38.      system.  An interactive standard, it attempts to reduce
  39.      retraining costs incurred by system-to-system variation.
  40.  
  41.      For utilities that have interactive as well as non-interactive
  42.      features, the UPE defines extensions from the base POSIX.2
  43.      utility.  One example is the shell, for which the UPE defines job
  44.      control, history, and aliases.
  45.  
  46. __________
  47.  
  48.   * UNIX is a registered trademark of AT&T in the U.S. and other
  49.     countries.
  50.  
  51. January 1990 Standards Update             IEEE 1003.2: Shell and tools
  52.  
  53.  
  54.                                 - 2 -
  55.  
  56. In my previous report, I noted two serious strategic problems with the UPE:
  57.  
  58.    - lack of coherence, and
  59.  
  60.    - lack of support.
  61.  
  62. The problems haven't disappeared.  (See the previous report for
  63. further information.)
  64.  
  65. Features used both interactively and in scripts tend to be defined in
  66. the base standard.
  67.  
  68. Status of POSIX.2 Balloting
  69.  
  70. ``Dot 2 Classic'' remains in its second round of balloting on Draft 9.
  71. Hal Jespersen, the POSIX.2 Technical Editor, thinks the forthcoming
  72. Draft 10 will go to ballot in June or July, Some early subsets of
  73. Draft 10 were in evidence at the working group meeting, but
  74. circulation is still restricted to those feeding changes into the
  75. Technical Review Process (so, no, you won't be able to get one
  76. yet...).  Draft 10 involves fewer people than the ten or so technical
  77. reviewers that produced Draft 9.  On one hand, fewer people means
  78. fewer ulcers for Hal Jespersen, who must co-ordinate myriad changes
  79. from as many quarters.  On the other, too few people produces a closed
  80. process, which extends the number of rounds of balloting required for
  81. final resolution.
  82.  
  83. Because the first round of balloting (Draft 8) produced many
  84. objections that were only partially resolved by Draft 9, and because
  85. issues often have several sides to consider, the Draft 10 balloting,
  86. starting this summer, has only a slim chance of creating the final
  87. standard.  That said, Dot 2 Classic's contentious areas appear to be
  88. narrowing to a small set of new inventions (create, hexdump, locale,
  89. localedef, etc).  I expect the objections to Draft 10 to be far fewer,
  90. and that the process is likely to converge to a full-use standard by
  91. Draft 11, late in 1990 or early in 1991.
  92.  
  93. On the UPE front, Draft 4 is scheduled to appear in February or March,
  94. so that a mock ballot may be held for the April meeting.  A mock
  95. ballot is a rehearsal for the real ballot -- real comments and
  96. objections are both prepared and resolved by the working group.  A
  97. real ballot shifts the focus from the working group to the balloting
  98. group.  The mock ballot is an excellent exercise, but communications
  99. within the working group tend to be excellent.  The process becomes
  100. more obscured once formal balloting begins, as shown by the extended
  101. balloting on Dot 2 Classic.  None the less, having distinct balloting
  102. and working groups ensures that the process has comments from all
  103. parties.
  104.  
  105. Formal (real) balloting for the future Draft 5 of the UPE should
  106. commence this fall.  A much smaller standard, the UPE is approaching
  107. the level of review that Dot 2 Classic had before it entered formal
  108. balloting.
  109.  
  110. January 1990 Standards Update             IEEE 1003.2: Shell and tools
  111.  
  112.  
  113.                                 - 3 -
  114.  
  115. Status of the New Orleans Meeting
  116.  
  117. Apart from a status report on the balloting of Dot 2 Classic, the New
  118. Orleans meeting focused on readying all UPE utility descriptions for
  119. mock balloting.  The working group reviewed existing utility
  120. descriptions in small groups of between three and six persons.  One
  121. group spent much of the week fleshing out arcane details of vi, only
  122. occasionally relieved by work on simpler utilities.
  123.  
  124. A group I worked in made the surprising discovery that uuencode, a
  125. utility traditionally used to convert binary files to a printable form
  126. to pass through mailers, is a utility to ``encode a binary file into a
  127. different binary file.'' This complexity arises from
  128. internationalization, where there are always several ways of looking
  129. at any problem.  Delve deeply into POSIX and ANSI C
  130. internationalization issues, and you'll always discover topics that
  131. the committees have not yet dealt with.  This is not a criticism of
  132. the internationalization standardization groups; much work is still
  133. needed and solutions to many problems remain elusive.  In the uuencode
  134. example, we felt the output of uuencode should be code-set invariant.
  135. I.e., uuencode on an EBCDIC system should produce the same results as
  136. uuencode on an ASCII or ISO 646 character system.  To achieve this,
  137. ' ' through '_' must be expressed as 0x20 through 0x5F and begin must be
  138. expressed as 0x62 0x65 0x67 0x69 0x6E (the hex equivalents of `b' `e'
  139. `g' `i' `n' in ASCII).  POSIX appears to offer no standard way to
  140. convert a file from one code set to another.
  141.  
  142. Attendance at the UPE working group was, again, relatively small --
  143. around a dozen people.  One reason is PAR proliferation.  Most
  144. companies cannot afford to send one committee member to each working
  145. group.  (I, for example, also had to cover TFA, POSIX.1b, and the
  146. internationalization efforts.) [Editor: Readers should note that that
  147. being spread thin didn't stop Randall from turning out a clear,
  148. thoughtful report.  Thanks, Randall.] Another reason is that there is
  149. less enthusiasm for the UPE than for Dot 2 Classic.  Even Hal
  150. Jespersen has said that ``...basically the NIST put our feet to the
  151. fire to do the UPE.''
  152.  
  153. Some people want the UPE to include an EMACS editor description as
  154. well as one for vi.  Unfortunately, although there was talk of an EMIN
  155. proposal, none was submitted to the working group.  If you EMACS fans
  156. want it included in the ever-expanding UPE, then submit a proposal.
  157. [Editor: Listen up, folks.  He's serious.] (Of course, some devotees
  158. feel that standardization would be inappropriate for an extensible
  159. environment like EMACS.)
  160.  
  161. ``Revision/Source Code Control Software'' is a much-shuffled area of
  162. future standardization within the overall POSIX.2 PAR.  Fearing
  163. another Tar Wars-like clash between fanatic supporters of of SCCS and
  164. RCS, the topic was removed from Dot 2 Classic and deferred to the UPE.
  165. The Source Code Control System (SCCS) is the original UNIX source code
  166.  
  167. January 1990 Standards Update             IEEE 1003.2: Shell and tools
  168.  
  169.  
  170.                                 - 4 -
  171.  
  172. control system which was implemented in the mid-1970's, modeled after
  173. mainframe systems of the time.  The more modern (no bias here...)
  174. Revision Control System, (RCS), by Walter Tichy of Purdue University,
  175. claims to have improved on SCCS.  Each has its proponents; SCCS
  176. appears to have a stronger following, because of commercial support by
  177. vendors, but RCS appears to have a more devoted underground following.
  178. The working group is divided between those who want either SCCS or RCS
  179. and those who want neither, arguing that source control is a vendor-
  180. specific application.  Unfortunately, the UPE working group has had
  181. problems resolving the controversy and Hal Jespersen has proposed that
  182. POSIX.2c (yes, you heard it right, .2c) be assigned as a PAR for
  183. working on this topic.  (What happened to .2b?  POSIX.2b is the
  184. working group that will prepare revisions and clarifications of Dot 2
  185. Classic -- which isn't even finished balloting.)
  186.  
  187. The next meeting will be in Snowbird, Utah (oops, we're supposed to
  188. say ``Salt Lake City''), the week of 23-27 April, 1990.
  189.  
  190. January 1990 Standards Update             IEEE 1003.2: Shell and tools
  191.  
  192.  
  193. Volume-Number: Volume 19, Number 50
  194.  
  195.