Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/csu.shar/37

Internet Message Format | 1988-12-19 | 10KB

Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 5: IEEE 1003.2
Message-ID: <[e-mail]>
Date: 11 Dec 88 16:44:10 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 223
Approved: [e-mail] (Moderator, John S. Quarterman)

[ 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
          [phone]
          [e-mail]
          uunet!bungia.mn.org!ahby


Volume-Number: Volume 15, Number 41