ahby@bungia.bungia.mn.org (Shane P. McCarron) (12/12/88)
[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information. -mod ]
An update on UNIX|= Standards Activities - Part 5
POSIX 1003.2 Update
November 18, 1988
Shane P. McCarron, NAPS International
1003.2 - Shell and Tools Interface
This working group never ceases to impress me. In September
the group was given about three weeks to go over draft 7 of
the standard and review it as if it were a formal ballot.
This means that problems discovered in the draft must be
reported to the committee using the formal POSIX balloting
format, within the specified time limits, in order to be
considered. A surprising number of people were able to work
very hard and come up with about 1500 objections to the 600
page document.
Okay, so a lot of people, given 3 weeks, can really find a
lot of problems with a somewhat immature document. Maybe
not terribly impressive. Then a group of 40 people meet in
Hawaii, not a place known to be conducive to work, and
manage to review every single objection and resolve them!
This is truly amazing, and I think everyone at that meeting
(including myself) deserves a medal. Moreover, I would like
to take this opportunity to publicly eat the words I wrote
last quarter. They may just pull it off! The draft that
goes out for balloting in the formal IEEE process is
certainly in much better shape than the 1003.1 document was
when it first went out. Also, P1003 learned a lot from the
.1 ballot, and that knowledge should help make the balloting
of .2 smoother.
Reaching back a bit for a transition, there were 1500
objections. That is really quite a few, but its not as bad
as it sounds (unless you had to carry them around for a
week). It is true that many changes were made to the
standard, and I couldn't tell you what most of them were.
What I can tell you is that they were primarily
inconsequential. Some objections requested changes in
functionality or interface, pointing out existing or new
practice that should be standardized. But all of the rest
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
- 2 -
can be broken down to spelling or grammatical corrections,
requests for clarification, or questions about the necessity
of specifications or lack of same. Some specific changes of
interest were:
o+ Based on a decision from the previous meeting and
several balloting objections, the fgrep and egrep
commands have been removed from the standard, and the
functionality that they provide is being encompassed in
the definition of grep. This new grep will have
options -E and -F which will give it the exact
functionality of egrep or fgrep, respectively.
o+ The draft has a command in it called colldef. Colldef
allows the portable definition of collating sequences,
which can then be used by utilities that do string
comparisons with the C Standard function strcoll. The
theory goes that an implementation will provide
applications with a means for creating collation
sequence definitions (colldef), and then also allow the
application to specify which collation sequence to use
when calling utilities like sort (through the
environment variable LC_COLLATE).
It all sounds pretty good, but the definition of
colldef was so incomplete and confusing that some
balloters suggested it be removed from the standard
altogether. The definition of this utility now
provides for a lot of additional functionality, and is
much clearer than it used to be. While this part of the
standard is not talked about much, I believe that it is
probably the most important part. The international
aspects of POSIX are sort of obscure, but they will
allow for more portable applications, and also allow
for some previously unheard of uses for utilities like
sort.
o+ A closely related utility, xform, was placed in the
standard to allow for the transformation of strings by
a shell script just as can be done using the strxfrm
function in Standard C. After much discussion in the
small group, this command was removed from the draft.
While there was some dissenting opinion, the majority
thought that this would have very limited usefulness to
a portable shell application. As I was the dissenter,
I can say that I wanted it in because there is no other
way to portably compare strings in the shell from an
international perspective. If a user enters something
and then later you want them to enter it again, you
cannot portably compare those strings without the xform
utility. Alas, you win some...
- 3 -
o+ An interesting development was the decision that the C
language functions in the standard be moved into a
chapter for C Language interfaces, and that their
original position in the document be reserved for the
language independent descriptions of some of the
functions. In the end it may be that some of the
functions are really not ones that need to exist in
other languages, and as such should not be in the
language independent section. This event is
interesting because it shows the intent of this working
group, and indeed all of the POSIX working groups, to
describe their standards in a language independent
manner. This was a requirement of the international
community, and I am glad to see that it is being
carried out.
o+ In what I consider a victory for the users of the
world, the UUCP style commands in the standard have
been moved out of the document and into an appendix.
These commands, uuxqt and uuname, have been in the
standard for about a year, but no one could really
figure out why. As described there was no underlying
transport mechanism or protocol defined, so they could
not possibly have been reliable in any event. They
were placed in the standard as a spear; something that
you could throw out and have no idea if it worked or
not. The working group has now realized that this is
not really a service to the application developer, and
has moved the commands (and concepts) into an appendix.
Depending on the feeling of the balloting group, these
commands will either be fleshed out into a full
definition of the UUCP "networking" system, or removed
from the standard altogether. It may be that these
concepts will fit into the P1003.8 standard on
networking, but I doubt it. While it is probably the
most widely used form of electronic networking on UNIX
systems, it is not really something that should be
carried into the future.
o+ While the UUCP commands are gone, the message sending
command sendto is still in the standard. This command
allows an application to send text to an address with
an implementation defined format to be deposited in an
implementation defined location and delivered in an
implementation defined manner. No kidding. That's
what it says. It also used to say sendto -r would try
to read from your personal implementation defined
storage location, but that it might not do anything.
Fortunately, the working group couldn't figure out a
single reason why a portable application would want to
read mail. While this is usually not enough cause to
- 4 -
remove something from a standard, when coupled with the
danger that it might not do anything if executed, the
evidence seemed to lean toward removal. This option
has been axed.
o+ There is now a section of the standard on application
installation. Actually, there has always been a
section for that, but until now it has been full of
stuff that wasn't really worth reading. The new
definition is a little bit complex, but it seems to be
fine. It allows for an application, on installation,
to determine what system resources are available, and
to then sort of dynamically inform itself about them.
There is also a system resource database, and all sorts
of other neat stuff. I don't have a handle on all of
it yet, so stay tuned. If I decide I hate it, I will
be sure to let you know.
There were all sorts of other changes made to the draft, but
they are primarily editorial, and are of course all subject
to review by the balloting group.
The schedule for balloting goes something like this:
Assuming the document gets to the balloting group in mid-
january, the period will close in mid-february. Then all of
the received objections will have to be resolved or
commented on, and it will be recirculated. This may happen
several times before the document is finalized. Since each
recirculation/resolution period takes 3 to 4 months, it
could be early 1990 before we see a ratified standard.
In the mean time, since the working group doesn't have
anything to do with a standard while it is going through
balloting, work will progress on the new User Portability
Extensions supplement. The idea here is that a supplement
to 1003.2 will be released soon after the initial standard.
This supplement will describe the traditional UNIX utilities
that have user interfaces (e.g. vi). Note that the
utilities to be described are the traditional ones, and have
nothing to do with windowing/mouse interfaces. Work on that
topic is progressing in other areas.
I am the Watchdog committee contact for 1003.2:
Shane P. McCarron
NAPS International
117 Mackubin St.
Suite 6
St. Paul, MN 55102
+1 (612) 224-9239
ahby@bungia.mn.org
uunet!bungia.mn.org!ahby
Volume-Number: Volume 15, Number 41gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/13/88)
From: gwyn@smoke.BRL.MIL (Doug Gwyn ) In article <273@longway.TIC.COM> Shane P. McCarron <ahby@bungia.bungia.mn.org> writes: >This new grep will have options -E and -F ... Eek! I thought the original 1003.2 intent was to permit implementation in a monocase command-line environment. Has that been discarded? Volume-Number: Volume 15, Number 48
ahby@bungia.bungia.mn.org (Shane P. McCarron) (12/14/88)
From: Shane P. McCarron <ahby@bungia.bungia.mn.org> > From: gwyn@smoke.BRL.MIL (Doug Gwyn ) > > Eek! I thought the original 1003.2 intent was to permit implementation > in a monocase command-line environment. Has that been discarded? I have been in the .2 group since their first real meeting, and that was never discussed as an option. If we are codifying existing practice, then this clearly cannot be achieved. While requiring a single grep is not "codifying existing practice", it does permit existing practice, while still giving a view to the future. -- Shane P. McCarron UUCP: ahby@bungia.mn.org Systems Analyst ATT: +1 612 224-9239 Volume-Number: Volume 15, Number 51