Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!cs.utexas.edu!longway!std-unix From: ahby@bungia.bungia.mn.org (Shane P. McCarron) Newsgroups: comp.std.unix Subject: Standards Update, Part 5: IEEE 1003.2 Message-ID: <273@longway.TIC.COM> Date: 11 Dec 88 16:44:10 GMT Sender: std-unix@longway.TIC.COM Reply-To: Shane P. McCarron Lines: 223 Approved: jsq@longway.tic.com (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 +1 (612) 224-9239 ahby@bungia.mn.org uunet!bungia.mn.org!ahby Volume-Number: Volume 15, Number 41