Path: gmdzi!unido!mcsun!uunet!snorkelwacker!usc!!longway!std-unix
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-ID: <620@longway.TIC.COM>
Date: 4 Apr 90 06:59:32 GMT
Sender: std-u...@longway.TIC.COM
Lines: 193
Approved: (Moderator, John S. Quarterman)
Posted: Wed Apr  4 07:59:32 1990

From: <>

            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools Update

Randall Howard <> reports on the January 8-12, 1990
meeting in New Orleans, LA:

Background on POSIX.2

The POSIX.2 standard deals with the shell programming language and
utilities.  Currently, it is divided into two pieces:

   + POSIX.2, the base standard, deals with the basic shell
     programming language and a set of utilities required for
     application portability.  ``Application portability'' essentially
     means portability of shell scripts and excludes most interactive
     features.  In an analogy to the ANSI C standard, the POSIX.2
     shell command language is the counterpart of the C programming
     language, while the utilities play, roughly, the role of the C
     library.  POSIX.2 also standardizes command-line and function
     interfaces of some POSIX.2 utilities (e.g., popen(), regular
     expressions, etc.) This document is also known as ``Dot 2

   + POSIX.2a, the User Portability Extension or UPE, supplements the
     base POSIX.2 standard; it will become a non-normative (optional)
     chapter of some future draft of the base document.  The UPE
     standardizes commands, such as screen editors, that might not
     appear in shell scripts but that users must learn on any real
     system.  An interactive standard, it attempts to reduce
     retraining costs incurred by system-to-system variation.

     For utilities that have interactive as well as non-interactive
     features, the UPE defines extensions from the base POSIX.2
     utility.  One example is the shell, for which the UPE defines job
     control, history, and aliases.


  * UNIX is a registered trademark of AT&T in the U.S. and other

January 1990 Standards Update             IEEE 1003.2: Shell and tools

                                - 2 -

In my previous report, I noted two serious strategic problems with the UPE:

   - lack of coherence, and

   - lack of support.

The problems haven't disappeared.  (See the previous report for
further information.)

Features used both interactively and in scripts tend to be defined in
the base standard.

Status of POSIX.2 Balloting

``Dot 2 Classic'' remains in its second round of balloting on Draft 9.
Hal Jespersen, the POSIX.2 Technical Editor, thinks the forthcoming
Draft 10 will go to ballot in June or July, Some early subsets of
Draft 10 were in evidence at the working group meeting, but
circulation is still restricted to those feeding changes into the
Technical Review Process (so, no, you won't be able to get one
yet...).  Draft 10 involves fewer people than the ten or so technical
reviewers that produced Draft 9.  On one hand, fewer people means
fewer ulcers for Hal Jespersen, who must co-ordinate myriad changes
from as many quarters.  On the other, too few people produces a closed
process, which extends the number of rounds of balloting required for
final resolution.

Because the first round of balloting (Draft 8) produced many
objections that were only partially resolved by Draft 9, and because
issues often have several sides to consider, the Draft 10 balloting,
starting this summer, has only a slim chance of creating the final
standard.  That said, Dot 2 Classic's contentious areas appear to be
narrowing to a small set of new inventions (create, hexdump, locale,
localedef, etc).  I expect the objections to Draft 10 to be far fewer,
and that the process is likely to converge to a full-use standard by
Draft 11, late in 1990 or early in 1991.

On the UPE front, Draft 4 is scheduled to appear in February or March,
so that a mock ballot may be held for the April meeting.  A mock
ballot is a rehearsal for the real ballot -- real comments and
objections are both prepared and resolved by the working group.  A
real ballot shifts the focus from the working group to the balloting
group.  The mock ballot is an excellent exercise, but communications
within the working group tend to be excellent.  The process becomes
more obscured once formal balloting begins, as shown by the extended
balloting on Dot 2 Classic.  None the less, having distinct balloting
and working groups ensures that the process has comments from all

Formal (real) balloting for the future Draft 5 of the UPE should
commence this fall.  A much smaller standard, the UPE is approaching
the level of review that Dot 2 Classic had before it entered formal

January 1990 Standards Update             IEEE 1003.2: Shell and tools

                                - 3 -

Status of the New Orleans Meeting

Apart from a status report on the balloting of Dot 2 Classic, the New
Orleans meeting focused on readying all UPE utility descriptions for
mock balloting.  The working group reviewed existing utility
descriptions in small groups of between three and six persons.  One
group spent much of the week fleshing out arcane details of vi, only
occasionally relieved by work on simpler utilities.

A group I worked in made the surprising discovery that uuencode, a
utility traditionally used to convert binary files to a printable form
to pass through mailers, is a utility to ``encode a binary file into a
different binary file.'' This complexity arises from
internationalization, where there are always several ways of looking
at any problem.  Delve deeply into POSIX and ANSI C
internationalization issues, and you'll always discover topics that
the committees have not yet dealt with.  This is not a criticism of
the internationalization standardization groups; much work is still
needed and solutions to many problems remain elusive.  In the uuencode
example, we felt the output of uuencode should be code-set invariant.
I.e., uuencode on an EBCDIC system should produce the same results as
uuencode on an ASCII or ISO 646 character system.  To achieve this,
' ' through '_' must be expressed as 0x20 through 0x5F and begin must be
expressed as 0x62 0x65 0x67 0x69 0x6E (the hex equivalents of `b' `e'
`g' `i' `n' in ASCII).  POSIX appears to offer no standard way to
convert a file from one code set to another.

Attendance at the UPE working group was, again, relatively small --
around a dozen people.  One reason is PAR proliferation.  Most
companies cannot afford to send one committee member to each working
group.  (I, for example, also had to cover TFA, POSIX.1b, and the
internationalization efforts.) [Editor: Readers should note that that
being spread thin didn't stop Randall from turning out a clear,
thoughtful report.  Thanks, Randall.] Another reason is that there is
less enthusiasm for the UPE than for Dot 2 Classic.  Even Hal
Jespersen has said that ``...basically the NIST put our feet to the
fire to do the UPE.''

Some people want the UPE to include an EMACS editor description as
well as one for vi.  Unfortunately, although there was talk of an EMIN
proposal, none was submitted to the working group.  If you EMACS fans
want it included in the ever-expanding UPE, then submit a proposal.
[Editor: Listen up, folks.  He's serious.] (Of course, some devotees
feel that standardization would be inappropriate for an extensible
environment like EMACS.)

``Revision/Source Code Control Software'' is a much-shuffled area of
future standardization within the overall POSIX.2 PAR.  Fearing
another Tar Wars-like clash between fanatic supporters of of SCCS and
RCS, the topic was removed from Dot 2 Classic and deferred to the UPE.
The Source Code Control System (SCCS) is the original UNIX source code

January 1990 Standards Update             IEEE 1003.2: Shell and tools

                                - 4 -

control system which was implemented in the mid-1970's, modeled after
mainframe systems of the time.  The more modern (no bias here...)
Revision Control System, (RCS), by Walter Tichy of Purdue University,
claims to have improved on SCCS.  Each has its proponents; SCCS
appears to have a stronger following, because of commercial support by
vendors, but RCS appears to have a more devoted underground following.
The working group is divided between those who want either SCCS or RCS
and those who want neither, arguing that source control is a vendor-
specific application.  Unfortunately, the UPE working group has had
problems resolving the controversy and Hal Jespersen has proposed that
POSIX.2c (yes, you heard it right, .2c) be assigned as a PAR for
working on this topic.  (What happened to .2b?  POSIX.2b is the
working group that will prepare revisions and clarifications of Dot 2
Classic -- which isn't even finished balloting.)

The next meeting will be in Snowbird, Utah (oops, we're supposed to
say ``Salt Lake City''), the week of 23-27 April, 1990.

January 1990 Standards Update             IEEE 1003.2: Shell and tools

Volume-Number: Volume 19, Number 50

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.