Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/posix.2

Text File | 1991-09-06 | 10.6 KB | 412 lines

.\" ts -mm %
.\" Constant width font
.ds Cw CR
.\" Make \*C mean - go into constant width - courier - mode
.\" the \& inserts a small space before the word and looks much better
.ds C \&\f(CR
.ds Rh "POSIX.2: Shell and Utilities
.ds Au "David Rowley <[e-mail]>
.ds Dt "July 8-12
.ds Lo "Santa Clara, CA
.ds Ed "Stephen Walli <[e-mail]>
.ds Wd "USENIX Standards Watchdog Committee
.if '\*(Su'' \{\
.ds Su "the \*(Dt meeting in \*(Lo:
.\}
.if n \{\
.tm Subject: Standards Update, \*(Rh
.tm From: \*(Ed
.tm Reply-To: [e-mail]
.tm Organization: \*(Wd
.tm
.\}
.AU "\*(Wd"
.AF "\*(Ed, Report Editor"
.MT 4
.if n \{\
.nh
.na
.\}
.S 12
Report on \*(Rh
.sp
.P
\fB\*(Au\fP
reports on \*(Su
.HU "Summary"
.SM POSIX.2
(Shell and Utilities) Draft 11.1 closed its recirculation
ballot on July 19.
This draft was circulated as the 250 pages that
had changed from Draft 11.
Balloting a ``changes-only'' draft proved
to be a challenge in itself.
\s-1POSIX.2a\s0 (User portability extension)
Draft 7 closed its recirculation ballot on August 19.
.P
.SM POSIX.2b
has been approved after a number of recommendations from the
Project Management Committee.
The
.SM POSIX.2
group continued work on
the new
.SM PAX
archive format.
Most of the time was again spent in a joint
meeting with
.SM POSIX.3.2
(Test Methods for
.SM POSIX.2 )
creating test assertions for the document.
.P
.HU "Background"
A brief \s-1POSIX.2\s0 project description:
.DL
.LI
.SM POSIX.2
is the base standard
dealing with the basic shell programming language and a set of utilities
required for
the portability of shell scripts.
It excludes most features that might be considered interactive.
.SM POSIX.2
also standardizes command-line and function interfaces related to certain
.SM POSIX.2
utilities
(e.g., \fIpopen()\fP, regular expressions, etc.).
This part of
.SM POSIX.2 ,
which was developed first,
is sometimes known as ``Dot 2 Classic.''
.LI
.SM POSIX.2a ,
the User Portability Extension or
.SM UPE ,
is a supplement to the base
standard.
It standardizes commands,
such as \fIvi\fP,
that might not appear in shell scripts,
but are important enough that users must learn them on any real system.
It is essentially an interactive standard,
and will eventually be an optional chapter
to a future draft of the base document.
This approach allows the adoption of the
.SM UPE
to trail Dot 2 Classic without delaying it.
.P
Some utilities have both interactive
and non-interactive features.
In such cases, the
.SM UPE
defines extensions from the base
.SM POSIX.2
utility.
Features used both interactively and in scripts
tend to be defined in the base standard.
.LI
.SM POSIX.2b
is a newly approved project which will cover
extensions and new requests from other groups,
such as utilities for the
.SM POSIX.4
(Realtime) and
.SM POSIX.6
(Security) documents.
.LE
.P
Together, Dot 2 Classic and the
.SM UPE
will make up the International Standards Organization's
\s-1ISO\s0 9945-2\*(EM\
the second volume of the proposed
.SM ISO
three-volume
.SM POSIX
standard.
.P
.HU "POSIX.2 Status"
.P
Resolution of \s-1POSIX.2\s0 Draft 11 ballot objections was completed,
and a Draft 11.1 was re-circulated.
There were 900 objections
received for Draft 11.
The Draft 11.1 recirculation ballot
closed July 19.
.P
This draft was circulated as a 250 page
``changes-only'' document.
This is created by printing the document and extracting all those
pages containing change bars.
Although this saves paper,
it makes
balloting extremely difficult.
The context of the changes is lost.
Since the page numbers (and even some
section numbers) have changed since Draft 11,
cross referencing old drafts doesn't help
much.
.P
The intent of this technique is to
physically demonstrate the increase in consensus
by the smaller size of
the document.
Even though balloting is made more difficult,
I agree with the
spirit of this approach,
since most of the changes between Draft 11
and Draft 11.1 were fairly minor clarifications of the wording.
.P
One advantage of the ``changes-only'' approach is that it
helps to prevent
balloters from commenting on those items
that have not changed since the last draft.
This is a restriction
placed on recirculation ballots.
You can't object to something you can't see!
.P
The complete Draft 11.1 document
is available from the \s-1IEEE\s0
for copying costs.
Draft 11.2 is already in the works,
and should appear sometime in
September or October.
.P
There have been a few requests lately to amend the \s-1POSIX.2\s0
project's base documents
list.
This is a list of documents which may be referenced
when discussing existing practice issues.
The \s-1OSF\s0's Application Environment Specification (\s-1AES\s0) is one
such candidate for addition.
.P
Draft 9 of
.SM POSIX.2
is currently an \s-1ISO\s0 committee document.
The
.SM ISO
standards process sees a document move through three phases on its way to
standardization \*(EM
Committee Document, Draft International Standard, and finally
International Standard.
.SM ISO
has requested the U.S. Member Body
to forward to them another draft once it has become more stable.
Draft 11.2 has been recommended for this, when it becomes available.
.P
Draft 11.3
should be out sometime in December.
It should be complete from
a technical standpoint.
Hal Jespersen,
the
.SM POSIX.2
Chair,
reported that final \s-1IEEE\s0 approval of
.SM POSIX.2
as a full-use standard will be delayed until all
.SM ISO
concerns have been addressed.
This could mean postponing the
.SM IEEE
.SM POSIX.2
standard until the middle of 1992.
I don't completely understand why the
.SM ISO
concerns cannot be addressed now, through
.SM ISO
responses to the Committee Documents sent to them.
This will no doubt be discussed heavily in the months ahead.
.P
.HU "POSIX.2a Status"
.P
Ballot resolution for \s-1POSIX.2a\s0 (\s-1UPE\s0) Draft 6 was completed.
There were only
400 objections.
Draft 7 was produced and recirculated,
and the ballot
closed August 19.
Ballot resolution is ongoing.
.P
The list of
.SM POSIX.2a
utilities is now stable.
There should not
be any additions or deletions.
The technical content of the
standard should be wrapped up in the first quarter of 1992.
Draft 6 of
.SM POSIX.2a
was submitted to
.SM ISO
as a proposed Committee Document/Proposed Draft Amendment (PDAM)
for eventual balloting as
.SM ISO
9945-2, Amendment 1.  Due to some procedural problems, it was changed to
a Review and Comment draft.  The next draft of
.SM POSIX.2a
will likely be Draft 8, a full draft.  This will also be forwarded to the
.SM ISO ,
as a Proposed Draft Amendment, and will hopefully make it this time.  Expect
the approval of
.SM POSIX.2a
as a full-use standard anywhere from three to six months after
.SM POSIX.2 .
.P
.HU "Project Management Committee Review"
.P
Both
.SM POSIX.2
and
.SM POSIX.2a
are up for review by the
Project Management Committee (\s-1PMC\s0) in October.
Each project will be
examined to ensure that the work is fulfilling its mandate.
.P
The \s-1PMC\s0 has recommended that the proposed project request (\s-1PAR\s0)
for \s-1POSIX.2b\s0 deal strictly with
new utilities.
The
.SM ISO
timing and formatting issues originally included in the
scope of \s-1POSIX.2b\s0 were thought to be unnecessary.
.P
.SM POSIX.2b
will include utilities from the
other \s-1POSIX\s0 working groups.
These working groups may allocate chapters in the
standard in a similar fashion to
.SM POSIX.2a .
Each group retains control of its chapter.
This is preferable to delegating the specification of the utilities
to the existing
.SM POSIX.2
working group,
which may not have the required expertise.
.P
One question arose from this: as the work of other groups is integrated into
POSIX.2 should those other groups' base
documents automatically be added to those of
.SM POSIX.2 ?
.P
.HU "New PAX Archive Format"
.P
Work continued on the new
.SM PAX
archive format.
No new proposals were forthcoming,
and the group continued working
in its current direction.
The intent is to build a new archive
format on top of the
.SM ISO
1001 tape standard.
The current new format specification
does not draw a clear line between what is part
of the
.SM ISO
format,
and what was added for
.SM PAX .
This will be remedied in a subsequent draft.
.P
I have reconsidered my earlier challenges to basing
this new format on
.SM ISO
1001.
It does have tangible benefits,
and should make transferring tapes between non-traditional environments
easier.
The current proposal addresses both tape and non-tape based
formats.
.P
Unfortunately, the
current
.SM POSIX.2
working group does not seem to have a great deal
of enthusiasm for this project.
Progress is slow.
Unless
someone champions this new format,
it may well stall.
Mark Brown (\s-1IBM\s0)
has volunteered to flesh out the current draft for distribution in the
next
.SM POSIX.2
mailing.
.P
.HU "Test Plans and Assertions"
.P
A test plan for
.SM POSIX.2
and
.SM POSIX.2a
was written,
and
submitted to
.SM POSIX.3.2
(Test Assertions for
.SM POSIX.2 )
for review.
Lowell Johnson,
.SM POSIX.3.2
Chair,
expressed
some concerns over the linkage of the
.SM POSIX.2
and the
.SM POSIX.2a
test
plans.
It is important that each test plan cover the scope of one
and only one project.
.P
Tuesday to Friday were spent writing test assertions in a
joint meeting between
.SM POSIX.2
and
.SM POSIX.3.2 .
Confusion continues to reign when writing assertions.
There are many
different assertion styles,
and it seems to be more art than science.
Styles range from ``you know what I mean'',
to precise, verbose,
legalese.
The group requested that the Chair (Lowell Johnson)
and the Technical Editor (Andrew Twigger)
produce a style guide for POSIX.3.2 assertions.
The guide would be reviewed at the beginning of each joint meeting.
This should greatly help the consistency of
the assertions being produced.
.P
Draft 5 of
.SM POSIX.3.2
is now 400 pages,
and most of the
.SM POSIX.2
commands have
assertions.
The group is still intending to mock ballot the document after
the October meeting.
A few utilities are
noticeably absent: \*Cawk\fP, \*Clex\fP, and \*Cyacc\fP.
I'm sure donations of
good assertions for these utilities would be most welcome.
.P
The turnout for the joint meetings was disappointing.
Writing
test assertions is time consuming hard work.
Ideally the joint meeting time
should be spent \fIreviewing\fP assertions,
and clarifying the implied interpretations of the standard.
Unfortunately,
it is difficult for members to find the time between
meetings to write assertions.
.P
Writing test assertions for \s-1POSIX.2a\s0 will likely start in January 1992.
If you thought test assertions for \*Cmake\fP were difficult,
wait until you try \*Cvi\fP!