Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-ID: <453@longway.TIC.COM>
Date: 2 Dec 89 19:20:41 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 95
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.0: POSIX Guide Update
Kevin Lewis < kle...@gucci.enet.dec.com> reports on the October 16-20,
1989 meeting in Brussels, Belgium:
Dot Zero's mission in Brussels was to step back and review where the
group had been, where we were, and where we needed to go. When we did,
we saw that we hadn't gone quite where we had wanted. This has
brought us to a place we don't necessarily want to be and will make
the remaining trip to where we plan to go longer than we'd like. I'll
quickly add that we are now headed in the right basic direction but
still need to make some course corrections.
There are two major contributors to this state of affairs. First, an
honest review of the pre-Brussels document reveals that it still has
significant holes. Also, its format makes what is there hard to
follow. I must admit that it felt good to see unanimous (yes,
unanimous) consent on both the need to re-organize the document and on
a new format. It does a co-chair's heart good to see two such rare
events occur concurrently. The reformatting of the draft guide will be
complete by the January meeting in New Orleans. The group will then
review components of the document that are sufficiently complete
section-by-section and line-by-line.
Second, Dot Zero faces a problem that is becoming widespread in 1003
and TCOS-SS: a serious dilution of effort. Little did Dot Zero
realize, when it recommended the formation of a group to address a
windows standard (now 1201), that we would lose people who had been
shepherding key components of the Dot Zero guide. With the voracious
growth of Dot Ate (oops), I see no end to this in sight. The new
efforts have left us with no one to cover networking, graphics, or
windows, though it's possible that new folks in these areas will join
us in New Orleans. [Editor's note: Listen to this man. What are your
ideas about open systems in these areas? If you have something useful
to contribute, please contact someone on dot zero -- Kevin, for
example. Don't just wait until it's too late and then complain about
the result.]
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.0: POSIX Guide
- 2 -
Regarding internationalization (for which the current buzzword is
"I18N", because there are eighteen letters between the 'I' and the
'N'):
Everyone who attended the I18N study group meeting sponsored by Dot
Zero found it most interesting in the end when the question regarding
the group's future was posed. All those present tacitly agreed that
it would not be in the best interests of I18N efforts for this study
group to become a full-fledged working group. This study group would
best serve the industry as a forum for issue flagellation, soap-
boxing, and formation of proposals to the appropriate accredited
bodies. At the appropriate time, the I18N group will declare that its
time is up. When that will be is yet to be determined.
When the question of identifying the major contributors to the I18N
efforts arose, I did notice an effort on the part of OSF to remain at
arm's distance from X/Open, in light of OSF's membership in X/Open,
signifying its desire to maintain its own identity.
That's enough negatives. Is there an up-side to all this?. Yes,
absolutely. We have a re-organized document that will ease and
streamline the review process. We now have the eyes of the industry
and the press looking over our shoulders, eager to read our guide.
And we are reaching the point where fear of personal and professional
embarrassment is motivating those who have an interest in this
effort's succeeding (which is almost everyone, I think). These will
combine to help us meet our goal of readying a draft for review and
comment by ISO by the fall of 1990. (Why are you laughing...? GEE!!
I get no respect!!!)
December 1989 Standards Update IEEE 1003.0: POSIX Guide
Volume-Number: Volume 17, Number 81
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!uunet!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-ID: <454@longway.TIC.COM>
Date: 2 Dec 89 19:24:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 280
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.1: System services interface Update
Mark Doran < m...@inset.co.uk> reports on the October 16-20, 1989 meeting
in Brussels, Belgium:
P1003.1 is now a full-use standard, so interest in attending the
working group has wained somewhat. Attendance didn't get above
fifteen or so all week and was nearer half a dozen most of the time.
Even so, this was a bit low by comparison with recent meetings. So
where was everyone?
[Editor's note -- Notice that this is larger than the attendance at
typical meetings of, for example, dot nine. "Low attendance" is
relative.
Author's additional note -- And that's the frightening thing;
standards being established by as few as half a dozen _i_n_d_i_v_i_d_u_a_l_s.
This cannot be representative or balanced. Scary stuff, "...as we
take you on a journey, into the Standards Zone..."]
We were all lead to believe that meeting in Brussels was going to
further the cause of international participation in the POSIX process.
Several people I would normally expect to see, didn't show; Europe
must be too far from home for a lot of the regulars. Unfortunately,
neither did I see more than two or three European types (whom I would
not normally expect to see at POSIX) all week either. Oh well, I'm
sure it was a good idea really...
So what did those that showed get up to? Well, in chronological
order:
1. ISO 9945 Status and Document Format
2. P1003.1a Balloting
3. Transparent File Access
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.1: System services interface
- 2 -
4. Language-Independent Specification
5. Messaging
6. P1003.1b
In detail:
1. ISO 9945
[Editor's note -- ISO 9945 is, roughly, the ISO standard
engendered by and corresponding to the POSIX work.]
It looks like 9945 is going to be split up into three major
pieces, the first of which is founded upon the IEEE P1003.1-1988
standard. This piece is likely to include all the other system
interfaces as well (notably, the real time stuff from P1003.4).
The other two pieces will be based around utilities and system
administration.
The basic IS9945-1:1989 will be just the same as the regular,
ugly-green, dot-one book -- well almost. ISO has yet another
documentation format and the book will have to be squeezed to
fit it. And before you ask, this one doesn't allow line numbers
either. We are assured that making the changes is not a major
problem, but the working group has still requested a new
disclaimer telling readers that all mistakes are the fault of
ISO!
2. P1003.1a
[Editor's note -- This document (supplement A) is supposed to
contain clarifications of and corrections to P1003.1-1988, but
no substantive changes.]
The meeting discussed resolution issues from the first ballot.
Highlights included:
- the decision to withdraw the cuserid() interface; its loss
will not be sadly mourned since one can use other
interfaces to do the same job better.
- the addition of a new type name ssize_t (yes, two s's) to
represent signed size_t values; this has all sorts of uses
-- for example, in the prototype for read(). Currently,
the parameter specifying the number of bytes to be read()
is given as a size_t, but read() has been specified to
December 1989 Standards Update IEEE 1003.1: System services interface
- 3 -
return an int, which this may not be large enough to hold a
size_t character count. Moreover, read() may return -1 for
failure, or the number of characters read if the call was
successful.
The recirculation ballot happened between November 10-20; if you
care but didn't know that already, it doesn't matter because you
(and many others, I suspect) have missed your chance. This all
seems a bit fast but it does mean that P1003.1a will hit an ISO,
six-month, letter-ballot window; standards must progress you
know...
3. Transparent File Access
Isn't this a P1003.8 problem? Yes, but the chair of the TFA
committee came to talk about TFA semantics as they relate to
P1003.1.
The crux of the matter is that the TFA folks (all six of
them...) seem to have decided that standardizing NFS will do
nicely for TFA. Their chair wonders whether the rest of the
world (or, more accurately, the balloting group for a TFA
standard) will agree.
The answer from the dot one folks appears to be definitely not
(thank goodness)! There appear to be several arguments against
NFS as the TFA standard from dot one. These include:
- It is impossible to maintain full dot one semantics over a
network using NFS. Consider the last-close semantics, for
example, which can only be preserved over a network using a
connection-oriented protocol, which NFS is not.
- Transparent File Access should be _t_r_a_n_s_p_a_r_e_n_t; NFS isn't.
It is possible for operations that are logically sound to
fail because of network timeouts.
- NFS is a _d_e _f_a_c_t_o standard; why should it get an official
rubber stamp?
This appears to be a hot topic that many groups may have an
interest in, so there will be an "out-of-hours" meeting on TFA
at the New Orleans POSIX -- If you care at all, I suggest you
try to show up... [Editor's note -- If you do care but can't go
to New Orleans, we suggest either writing directly to the TFA
chair, Jason Zions < j...@hpcndr.cnd.hp.com>, or posting your
opinions to comp.std.unix.]
December 1989 Standards Update IEEE 1003.1: System services interface
- 4 -
4. Language-Independent Specification
It seems to have been decided that POSIX API standards should be
written in a language-independent form, i.e. not expressed in
C-language constructs.
My initial reaction was one of horror, but then someone quietly
pointed out to me that C is not the only programming language in
the known universe. This I have to concede, along with the idea
that bindings to POSIX APIs in other languages may not be such a
bad idea after all. Indeed work is well underway to produce
FORTRAN and ADA bindings.
But now it seems we have to express POSIX in a language-
independent way. "Why?" I ask... Well, this means that when
you come to write the next set of actual language bindings, the
semantics you'll need to implement won't be clouded with
language-dependent stuff; the idea is that you won't have to
understand C in all its "glory" to write new language bindings.
So what will the language-independent specifications look like?
Will I be able to understand those? The current proposal
doesn't look like anything I recognize at all. Yes, that's
right, we have to learn a whole NEW language (sigh). Why not
use a more formal specification language that a few people know?
(Like ASN.1 for example, which P1003.7 has decided to use.)
Better yet, why not use constrained English -- lots of people
can read that...
Come to think of it, since the FORTRAN and ADA bindings folks
have managed without the aid of language-independent
specifications, why can't everyone else? Is there more to this
than a glorified job creation scheme? ("Wanted: expert in POSIX
'language-independent' language...") If there is, do we have to
invent a new wheel to get the job done?
As you can tell, my opinion of this effort is somewhat
jaundiced. Perhaps, you may say, I have missed the point.
Maybe so; but if I have, I feel sure that some kind soul will be
only too happy to correct me in "flaming" detail :-)
5. Messaging
The UniForum internationalization (I18N) folks brought forward a
proposal for a messaging facility to be included in P1003.1b.
The working group decided that it needs some more work but will
go into the next draft.
[Editor's note -- The problem being solved here is that
internationalized applications store all user-visible strings in
external files, so that vendors and users can change the
December 1989 Standards Update IEEE 1003.1: System services interface
- 5 -
language of an application without recompiling it. The UniForum
I18N group is proposing a standard format for those files.]
6. P1003.1b
Work on production of the second supplement is still at a
formative stage. Indeed, the group is still accepting formal
proposals for functionality to add to the document. Where
P1003.1a has been drawn up as a purely corrective instrument,
P1003.1b may add new functionality. Among the interesting
things currently included are these:
- The messaging proposal described above.
- A set of interfaces to provide symbolic links. The basic
idea is that lstat(), readlink() and symlink() operate on
the link, and all other interfaces operate on the linked-to
file.
Rationale will be added to explain that '..' is a unique
directory, which is the parent directory in the same
physical file system. This means that cd does not go back
across symlinks to the directory you came from.
This is the same as the semantics on my Sun. For example:
(sunset) 33 % pwd
/usr/spare/ins.MC68020/md/train
(sunset) 34 % ls -ld ./MR_C++
lrwxrwxrwx 1 root 32 Sep 30 1988 MR_C++ -> /usr/sunset/md/c++/trainset/c++/
(sunset) 35 % cd MR_C++
(sunset) 36 % pwd
/usr/sunset/md/c++/trainset/c++
(sunset) 37 % cd ..
(sunset) 38 % pwd
/usr/sunset/md/c++/trainset
The rationale is meant to help keep readers' eyes on what's
really written in the standard and help them avoid
misinterpreting it along lines of their own potential
misconceptions.
- P1003.1b used to have two descriptions of Data Interchange
formats. Now it has only one. The working group picked
the one that remains because it more closely existing
December 1989 Standards Update IEEE 1003.1: System services interface
- 6 -
standards in the area, in particular the surviving proposal
refers to X3.27.
December 1989 Standards Update IEEE 1003.1: System services interface
Volume-Number: Volume 17, Number 82
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <465@longway.TIC.COM>
Date: 6 Dec 89 19:44:12 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 120
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.4: Real-time Extensions Update
John Gertwagen < jag@laidbak> reports on the November 13-17, 1989
meeting in Milpitas, CA:
Background
The P1003.4 Real-time Working Group, began as the /usr/group technical
committee on real-time extensions. About two years ago, it was
chartered by the IEEE to develop minimum extensions to POSIX to
support real-time applications. Over time its scope has expanded, and
P1003.4 is now more a set of general interfaces that extend P1003.1
than a specifically real-time standard. Its current work is intended
to support not only real-time, but also database, transaction
processing, Ada runtime, and networking environments. The group is
trying to stay consistent with both the rest of POSIX and other common
practice outside the real-time domain.
The work is moving quickly. Though we have only been working for two
years, we are now on Draft 9 of the proposed standard, and expect to
go out for ballot before the end of the year. To help keep up this
aggressive schedule. P1003.4 made only a token appearance at the
official P1003 meeting in Brussels. The goal of the Milpitas meeting
was to get the draft standard ready for balloting.
Meeting Summary
Most of the interface proposals are now relatively mature, so there
was a lot of i-dotting and t-crossing, and (fortunately) little
substantive change. The "performance metrics" sections of several
interface chapters still need attention, but there has been little
initiative in the group to address them, so it looks like the issues
will get resolved during balloting.
The biggest piece of substantive work was a failed attempt to make the
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.4: Real-time Extensions
- 2 -
recently introduced threads proposal clean enough to get into the
ballot. The stumbling block is a controversy over how to deal with
signals.
There are really two, related problems: how to send traditional
UNIX/POSIX signals to a multi-threaded process, and how to
asynchronously interrupt a thread.
Four options have been suggested: delivering signals to a (somehow)
privileged thread, per Draft 8; delivering a signal to whichever
thread is unlucky enough to run next, a la Mach; delivering the signal
to each thread that declares an interest; and ducking the issue by
leaving signal semantics undefined.
We haven't been able to decide among the options yet; the working
group is now split evenly. About half think signal semantics should
follow the principle of least surprise, and be fully extended to
threads. The other half think each signal should be delivered to a
single thread, and there should be a separate, explicit mechanism to
let threads communicate with one another.
(Personally, I think the full semantics of process signals is extra
baggage in the "lightweight" context of threads. I favor delivering
signals to a privileged thread -- either the "first" thread or a
designated "agent" -- and providing a separate, lightweight interface
for asynchronously interrupting threads. On the other hand, I would
be happy to see threads signal one another in a way that looks,
syntactically and semantically, like inter-process signals. In fact,
I think the early, simpler versions of signal() look a lot like what's
needed (around V6 or so). I don't care whether the implementation of
"process" and "thread" signals is the same underneath or not. That
decision should be left to the vendor.)
Directions
Draft 9 of P1003.4 is being readied for ballot as this is being
written and should be distributed by mid-December. With a little
luck, balloting will be over by the Summer of '90.
Threads is the biggest area of interest in continued work. The
threads chapter will be an appendix to Draft 9 and the balloting group
will be asked to comment on the threads proposal as if it were being
balloted. Unless there is a significant write-in effort, the threads
interface will probably be treated as a new work item for P1003.4.
Then, if the outstanding issues can be resolved expediently, threads
could go to ballot as early as April '90.
With the real-time interfaces defined, it looks like the next task of
this group will be to create one or more Real-time Application
December 1989 Standards Update IEEE 1003.4: Real-time Extensions
- 3 -
Portability Profiles (RAPPS?) that define how to use the interfaces in
important real-time application models. Agreeing on the application
models may be harder than agreeing on the interfaces, but we'll see.
December 1989 Standards Update IEEE 1003.4: Real-time Extensions
Volume-Number: Volume 17, Number 92
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!
longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/2: Networking (IPC)
Message-ID: <481@longway.TIC.COM>
Date: 18 Dec 89 05:24:57 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 169
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.8/2: Networking (IPC) Update
Steve Head < s...@hpda.hp.com> reports on the October 16-20, 1989
meeting in Brussels, Belgium:
OVERVIEW
P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX. The committee is
currently divided into six subcommittees: transparent file access,
network IPC, remote procedure call, OSI/MAP services, X.400 mail
gateway, and directory services.
This report is a summary of the activity in the network IPC
subcommittee, which is currently working on two potential interfaces,
a "detailed" interface (DNI) and a "simple" interface (SNI). DNI is
roughly (though not exclusively) at the transport level. SNI is
intended to be somewhat simpler to use than DNI, but at roughly the
same level.
At this meeting, presentations of DNI and SNI were made at the EC
(European Community) headquarters in Brussels. Discussions on DNI
(definitions) and SNI (routines) continued. The main topics of
discussion were:
1. DNI, SNI presentation to EC
2. DNI definitions
3. SNI routines
4. Schedule
5. Security
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.8/2: Networking (IPC)
- 2 -
6. P1003.8/2 -> full POSIX committee
DETAIL
1. DNI, SNI presentation to EC
Keith Sklower and Steve Head gave presentations on DNI and SNI
respectively to POSIX attendees at CEC (Commission of the
European Community) headquarters. This meeting was scheduled in
Brussels primarily to obtain European input. The presentations
went well, and attendees included X/Open and EC representatives.
No significant differences of opinion or direction were noted
between the committee and other attendees. This indicates some
degree of success (?). (Other networking groups, such as
directory services, were not so fortunate.)
This meeting "broke the ice" with international organizations in
the area of networking, and we now expect increased interaction
with those organizations.
2. DNI definitions
The committee discussed DNI definitions. Steve Head presented a
paper on the subject. Suggestions made at the meeting will be
incorporated into a future version of the paper, which will be
circulated via electronic mail. If no further significant
issues are raised, it will be incorporated into the next DNI
draft.
3. SNI routines
The committee discussed SNI routines, based on a paper from
Keith Sklower. No conclusions were reached, however, this
particular discussion was very useful since it brought a number
of goals and requirements for SNI into clear focus.
SNI is adopting some characteristics of ISODE (the ISO
Development Environment). This is probably beneficial since it
means that SNI will be partially based on a working
implementation instead of being entirely new. As such, it may
gain importance as a migration strategy for transferring
applications from TCP/IP to ISO. (ISODE stands for the ISO
Development Environment, a collection of networking software
available through public channels that runs over either TCP/IP
or ISO transport and allows higher level applications to be
December 1989 Standards Update IEEE 1003.8/2: Networking (IPC)
- 3 -
oblivious to the type of transport a given system provides.)
4. Schedule
The working schedule has been delayed by the need to make
presentations at Brussels, instead of doing "real work".
Originally, we had scheduled the topics of connection setup,
connection tear-down, and name resolution for this meeting.
These topics were not discussed, and our schedule has been
shifted back a quarter to reflect this. These topics will be
discussed at the next meeting. (See FUTURE MEETING TOPICS
below.)
5. Security
We held another joint meeting with the POSIX security group,
P1003.6. An electronic mailing list was created for the topic
of network security. For more info or to be put on the list,
please contact Mike Ressler (m...@bellcore.com or bellcore!mpr).
A list of topics on networking security to begin discussions on
was initiated.
6. P1003.8/2 -> full POSIX committee
The decision to make P1003.8/2 a full POSIX committee was
postponed by the POSIX executive committee (SEC). This subject
will be re-addressed at the next POSIX meeting in January.
December 1989 Standards Update IEEE 1003.8/2: Networking (IPC)
- 4 -
FUTURE MEETING TOPICS (TENTATIVE)
DATE ACTIVITY
--------------------------------------------------------------------
Winter 1990 mtg SNI/DNI connection setup/tear-down
Spring 1990 mtg SNI/DNI data transfer
Summer 1990 mtg SNI/DNI event management
Fall 1990 mtg SNI/DNI POSIX 1003.1 extensions
Winter 1991 mtg SNI/DNI protocol-independent options
Spring 1991 mtg SNI/DNI miscellaneous functionality
DNI protocol-dependent (ISO, ARPA, etc.) options
Summer 1991 mtg SNI/DNI definitions
Fall 1991 mtg SNI/DNI review drafts
Winter 1992 mtg SNI/DNI approve drafts for mock ballot
Jan. 1992 SNI/DNI mock ballot
Spring 1992 mtg SNI/DNI resolve mock ballot objections
Summer 1992 mtg SNI/DNI review drafts
Fall 1992 mtg SNI/DNI approve drafts for full use ballot
Nov. 1992 SNI/DNI full use ballot
Winter 1993 mtg SNI/DNI resolve full ballot objections
Spring 1993 mtg SNI/DNI resolve full ballot objections
May 1993 SNI/DNI submit approved drafts to IEEE stds. board
Summer 1993 data representation network interface goals ...
December 1989 Standards Update IEEE 1003.8/2: Networking (IPC)
Volume-Number: Volume 17, Number 108
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!
cs.utexas.edu!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-ID: <494@longway.TIC.COM>
Date: 6 Jan 90 15:08:21 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 205
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.2: Shell and tools Update
Randall Howard < r...@mks.com> reports on the October 16-20, 1989
meeting in Brussels, Belgium:
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 thus excludes most
features that might be considered interactive. 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 related to
certain POSIX.2 utilities (e.g., popen, regular expressions,
etc.) [Editor's note - This document is also known as "Dot 2
Classic".]
+ POSIX.2a, the User Portability Extension or UPE, is a supplement
to the base POSIX.2 standard; it will eventually be an optional
chapter of a future draft of the base document. The UPE
standardizes commands, such as screen editors, 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 that attempts to reduce retraining costs incurred by
system-to-system variation.
Some utilities, have interactive as well as non-interactive
features In such cases, the UPE defines extensions from the base
POSIX.2 command. An example is the shell, for which the UPE
defines job control, history, and aliases. Features used both
interactively and in scripts tend to be defined in the base
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.2: Shell and tools
- 2 -
standard.
In my opinion, the biggest current problem with the UPE is that it
lacks a coherent view: it's becoming a repository for features that
didn't make it into the base standard. For example, compress is in
the current UPE draft. It's hard to rationalize classifying file
formats as an "interactive" or "user portability" issue, yet the one
used by compress is specified in the UPE. It certainly doesn't fit in
with a view of the UPE as a standard that merely adds utility syntax
information (e.g., information that would allow users to type the same
command line to compress a file on any system). This highlights the
schizophrenic nature of the UPE: it addresses a range of different
needs that, taken together, do not appear to define a whole. Dot 2
Classic, to my taste, appears to have far more unified scope and
execution.
A second, related, problem with the UPE is that there appears to be
less enthusiasm for it than for the base standard. A number of
people, including me, understand the need for it, but it doesn't
appear to have the strategic importance of the base. [Editor's note -
The UPE is, frankly, controversial. Like 1201, the committee
undertook the UPE out of a fear that if they didn't, NIST would do the
job without them. Supporters note that although its utilities are
probably not necessary for portability of most software, it would be
unpleasant for programmers to do the porting work without them.
Detractors counter that POSIX was never intended to cover software
development and that the group is exceeding not only its charter, but
that of the entire 1003 committee.]
Status of POSIX.2 Balloting
POSIX.2 is in its second round of balloting. The first ballot, on
Draft 8, produced many objections that are only partially resolved by
Draft 9. Although there were only fifty-four pages of unresolved
objections remaining after Draft 9 was produced, the current balloting
round is not restricted to existing objections, and there will almost
certainly be many new ones. Remaining objections range from the
perennial war between David Korn and the UNIX Support Group over what
features should be required in the POSIX shell, through the resolution
of the incompatible versions (Berkeley and USG) of echo, to the
treatment of octal and symbolic modes in umask.
A digression to illustrate the kind of issues being addressed:
In March of 1989, a study group from 1003.2 met at AT&T to
resolve major objections to the shell specified in Draft 8 by the
two warring parties. This was a good place to hold the meeting,
since both parties are from AT&T: one led by David Korn of Bell
Labs, the author of the popular Korn Shell (KSH) the other, a
group led by Rob Pike of Bell Labs Research and the UNIX Support
Organization, advocating more traditional shells, like the System
December 1989 Standards Update IEEE 1003.2: Shell and tools
- 3 -
V Bourne Shell and the Version 9 Research shell. Korn's group
contends that the shell should be augmented to make it possible
to efficiently implement large scripts totally within the shell
language. For example, while the more traditional camp views
shell functions as little more than command-level macros and uses
multiple scripts to modularize large shell applications, the Korn
shell views functions as a tool for modularizing applications,
and provides scoping rules to encourage this practice.
The two philosophies engender different opinions on issues such
as the scoping of traps within functions and the use of local
variables. Other contentious issues were the reservation of the
brace ({ }) characters as operators (rather than as the more
tricky "reserved words"), the promotion of tilde expansion to a
runtime expansion (like parameter expansion), and the issue of
escape sequences within echo/print/printf.
The meeting produced a false truce. I attended, and believe that
both parties had different views of the agreement that came out
of the meeting. As a result, Draft 9 produced balloting
objections from both parties and the dispute continues unabated.
Shades of POSIX.1 Tar Wars...
I suspect the next draft (Draft 10) will fail to achieve the consensus
required for a full-use standard.
This is a good thing. Useful features are still finding their way
into the document. (Draft 9 introduces hexdump, locale, localedef,
and more.) Also, the sheer size (almost 800 pages) of Draft 9 has
prevented many balloters from thoroughly reviewing the entire
document, Still, there is a stable core of utilities that is unlikely
to change much more than editorially; I predict the standard will
become final around Draft 12.
A mock ballot on Draft 4 of the UPE will probably start after the New
Orleans meeting in January, and the resulting Draft 5 will probably go
to a real ballot somewhere in summer to early fall of 1990. Although
many sections remain unwritten or unreviewed, the UPE is a much
smaller standard than POSIX.2 and should achieve consensus more
quickly.
Status of the Brussels Meeting
The Brussels meeting focused on the UPE, with only a summary report on
the status of balloting for the base standard. For most of the
meeting, small groups reviewed and composed UPE utility descriptions.
The changes generated at the meeting will appear in Draft 3.
The groups reviewed many utilities. The chapter on modifications to
the shell language (for interactive features) is now filled in, and
such utilities as lint89 (the recently renamed version of lint), more,
December 1989 Standards Update IEEE 1003.2: Shell and tools
- 4 -
etc. are approaching completion. Still, much work remains.
[Editor's complaint - We think renaming common commands like lint
("lint89") and cc ("c89") is both cruel and unusual. We are not eager
to re-write every makefile and shell script that refers to cc or lint,
nor to re-train our fingers to find new keys each time the C compiler
changes. The name seems to have been coined by either a hunt-and-peck
typist, or someone who has longer and more accurate fingers than we
do. (Was it, perhaps, the work of Stu Feldman, author of f77?)
Moreover, replacing commands with newer versions is commonplace and
traditional in UNIX. Examples like "make", "troff", and "awk" spring
to mind. If an older version is kept on for die-hards, it's renamed
(e.g., otroff, oawk).
One Dot-Two member rebuffed our objections with the reply, "But, you
see, this isn't UNIX: it's POSIX." ]
Because the meeting was in Europe, attendance at the working group
meetings was lower than normal (20-25 rather than the normal 35-40 in
POSIX.2. Nevertheless, the choice of location served a purpose. The
meeting was held in Brussels to garner international support and
participation, particularly from the European Economic Community.
There were many EEC representatives at the background sessions on
POSIX and two or three European working group members in the POSIX.2
meetings who wouldn't normally have attended. Though it remains to be
seen what will come out of having met in Brussels, I am convinced that
the extra effort will prove to have been justified.
December 1989 Standards Update IEEE 1003.2: Shell and tools
Volume-Number: Volume 18, Number 4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada-language Binding
Message-ID: <492@longway.TIC.COM>
Date: 5 Jan 90 02:38:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 144
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.5: Ada-language Binding Update
Ted Baker < tba...@ajpo.sei.cmu.edu> reports on the October 16-20, 1989
meeting in Brussels, Belgium:
The P1003.5 group is producing an Ada-language binding for 1003.1.
The Brussels meeting had two objectives: to reach consensus on a draft
document to be distributed for mock ballot, and to solicit input from
the European community. We achieved the first but not the second;
only one of the ten attendees was European (Olle Wikstrom, from
Ericsson).
The technical editor (David Emery) and the chapter authors had worked
very hard between meetings to produce version 3.2 of the document, and
Dave brought copies to the meeting. The working group reviewed it to
try to correct any serious errors or omissions before mock ballot.
There was a lengthy discussion about schedule and logistics for the
mock ballot. The present plan is to send out copies of the next
draft, in ISO format, to both the ISO and the entire 1003.5 mock-
ballot mailing list. [Editor's note: All committees are re-formatting
their documents in ISO format to smooth the way for ISO acceptance
(see Dominic Dunlop's report on WG15 for more details), and an IEEE
copy editor appeared on the scene in Brussels to give P1003.5 guidance
and help in this.] Since there is no way that enough input can be
received before the next POSIX meeting, in January, the group has
scheduled a special meeting for mock ballot resolution, between the
January and April POSIX meetings, to be held in Tallahassee. The
objective will be to produce a proposed standard to be reviewed at the
April meeting.
Most technical issues discussed were minor, compared with previous
meetings. The most significant, and complicated, was the treatment of
system configuration limits. Here are three problem areas:
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 2 -
1. Tri-state configuration parameters (true, false, undefined) in
the POSIX C binding need to be treated differently in the Ada
binding, because Ada prohibits references to undefined symbols.
(I.e., Ada lacks an "#ifdef" facility.)
2. For the same reason, it isn't clear how an Ada binding can
accommodate future POSIX extensions. Suppose, for example, a
future extension adds a new configuration constant. How does
one write an Ada program that takes advantage of the new feature
on implementations where it's available without preventing the
same program from compiling on older implementations, where it's
not?
3. Because Ada compilers can do optimizations, such as dead code
elimination, based on static expressions (the nearest analog to
some C preprocessor capabilities), it is important to provide
compile-time constants, where safe. At the same time, to
support "bubble pack" software that is usable on different
system configurations, programs should also be able to defer
binding such values until run time.
The group did achieve consensus on a treatment of configuration limits
for the mock ballot. It includes a combination of functions, to allow
software to defer resolution of system limits and characteristics
until runtime, and implementation-defined constants and numeric
ranges, to allow optimizers to take advantage of information available
at compile time. This does not fully solve all the problems mentioned
above. Perhaps the mock ballot process will turn up some suggestions
for improvements.
The treatment of process arguments and environment variables, which
must be provided as parameters when starting a new process or calling
Exec produced another controversy.
Unlike C, Ada does not allow pointers to stack or statically allocated
objects. An Ada POSIX interface implemented over a C-language binding
must bridge this gap somehow. For example, an implementation might
use a C-compatible data structure and hide the non-Ada details, or use
an Ada data structure and translate between the two forms. Everyone
agreed that the interface should avoid constraining the
implementation, but the first interface solutions appeared to rule out
desirable implementations. The present solution permits an
application to insure that if the Ada POSIX interface machinery
allocates any "heap" storage this storage is be recovered, while
allowing an implementation to impose restrictions that would permit
stack allocation. A price paid for this compromise is that writing
portable applications takes more care: an application that works OK
with one implementation may lose storage or exceed size limits with
another.
At the previous two meetings, we had substantial interaction both with
December 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 3 -
other groups working on language-independence and with P1003.4 (real-
time). There was much less this time, partly because the group was
concentrating so hard on getting ready for mock ballot, partly because
meetings were spread over several buildings, and partly because
P1003.4 mostly skipped Brussels.
On the administrative side, Steve Deller was promoted from Vice
Chairman to Chairman (in charge of external affairs and running
meetings) and Jim Lonjers was chosen as Vice Chairman (in charge of
administering ballot resolution). This change was required because
the ex-Chairman (Maj. Terry Fong) has been unable to participate
regularly in the working group recently, owing to conflicts with his
professional duties.
Another issue that came up was whether working group members are at
liberty to publish papers or present talks on the 1003.5 work. The
answer is, "Yes." Until now, some members have been exercising self-
censorship, based on an earlier agreement designed to discourage
anyone (e.g., defense department personnel) from making commitments
(e.g., requiring use of the POSIX Ada binding in contracts) based on
erroneous (e.g., overly optimistic) progress reports. It did not take
much discussion to agree that such censorship is now
counterproductive, and may never have been wise. At this point,
P1003.5 certainly wants public exposure of its draft document, and
hopes that such exposure will generate more reviewers and active
working group members.
December 1989 Standards Update IEEE 1003.5: Ada-language Binding
Volume-Number: Volume 18, Number 2
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!longway!
std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration
Message-ID: <495@longway.TIC.COM>
Date: 6 Jan 90 15:14:45 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 130
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.7: System Administration Update
Steven J. McDowall < s...@mca.mn.org> reports on the October 16-20, 1989
meeting in Brussels, Belgium:
Background
Joe Friday would say, "Just the facts, ma'am." And that's the way I
feel. The facts are that I'm sick, it's Thanksgiving, I am going to
London for two weeks tomorrow, and 1003.7 is defining a standard way
to administer POSIX systems.
Now, almost everyone agrees that 1003.7 should deal with networks, not
just isolated systems. To wit, it would be nice if I could administer
all the machines in a network from a single machine with simple
commands. For example, to add a user to all machines in the domain
"mn.org", all I should need to do is issue a command like "adduser -d
mn.org -options -parameters username". The question is, without any de
facto standard already in place to adopt, how can we achieve this?
The Approach
This is important, so pay attention. Because the major goal of 1003.7
is to create a standard way to manage a set of objects, the group has
decided to take an object-oriented approach. Our idea is to begin by
creating a list of objects to manage, then to follow that by defining
the set of commands to manage each object. This approach is novel for
both system administration and POSIX. It will probably require more
work on the front end to define the objects, their attributes, and
their relationships, than to define the actual command structure to
support and manipulate them. Whether this approach will work remains
to be seen.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.7: System Administration
- 2 -
The Meeting
The meeting was boring. To put it bluntly, the week was simply a work
week. Objects (and sub-objects) were defined and discussed in detail,
then put in the draft. Little got done on the first and last days,
due to EEC formalities, which left us with three working days instead
of the normal four and a half. Attendance was pretty dramatically
reduced, too. About half the normal North Americans showed up,
probably because of the location, and only one (yes one...) new
European came even though we were meeting in Europe. Oh well, except
for my having had my passport stolen, it was a good chance to see
Belgium.
Concerns
1. The process is taking a long time to move ahead, both because of
the difficulty involved and because we seem to attract less
manpower than many other groups. Moreover, since we're taking a
radical approach, it takes extra time to teach the ideas to
anyone new that does come.
2. System administration doesn't have the glamour of some of the
other areas being standardized. As the Rodney Dangerfield of
POSIX, 1003.7 gets no respect.
3. The notation we're using to define our objects is ASN.1. "Why
ASN.1?" you ask. Simply because it's a standardized meta-
language to describe abstract data types. The feeling was that
this would help make the whole package more suitable for
interoperability. I bring this up because there's some movement
throughout 1003 to re-do all data structures in a new meta-
language created by some of the people working on language-
independence. Not only would this require that we go back and
re-do our definitions, but I also think ISO will only allow the
use of standardized data-languages in their standards. Does
anyone out there know if there is such an ISO restriction? If
so, it's important for 1003 as a whole, not just for dot seven.
4. Currently, almost all working-committee members are from
vendors. IBM, DEC, HP, AT&T, and others are well-represented.
A few interested parties, like OSF and /sys/admin. are there as
well, but as far as I can tell, there isn't one real user. By
"real user" I mean someone who does nothing but administer a
system. All of us are connected somehow with creating an
administrable system or getting paid to do so. Of course, I
should make clear that we all have to administer systems of our
own, so we're not simply an ivory tower group with no real
December 1989 Standards Update IEEE 1003.7: System Administration
- 3 -
experience, but representation is still grossly unbalanced.
5. Finally, there's been a loss of focus on interoperability
directly attributable to the loss of our X/OPEN representative,
Jim Oldroyd. Jim was well respected and made many valuable
contributions, but can no longer attend our meetings. As the
X/OPEN representative, he was very concerned with multi-vendor
environments, and was a major force in helping us focus on and
ensure interoperability. I am not saying that no one else on
the committee cares about the issue, but it does seem to be
being pushed aside in a spirit of, "I think we shouldn't have
any interoperability problems if we do this, so let's do it and
worry about it later on." Jim had helped provide a more
positive, direct approach of determining up front what would be
needed for true interoperability. If X/OPEN is still interested
in System Administration, and in making sure the 1003.7 standard
includes provisions for interoperability, we could still use
their help.
December 1989 Standards Update IEEE 1003.7: System Administration
Volume-Number: Volume 18, Number 5
|