home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso
/
std_unix
/
volume.12
< prev
next >
Wrap
Internet Message Format
|
1989-01-07
|
168KB
From jsq Sat Jul 18 13:54:38 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA14020; Sat, 18 Jul 87 13:54:38 EDT
From: std-unix%uunet.UUCP@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 12
Keywords: contents, index, summary, statistics
Message-Id: <668@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: std-unix@uunet.UU.NET
Date: 18 Jul 87 17:54:30 GMT
Apparently-To: std-unix-archive
This is the first article in Volume 12 of comp.std.unix.
The USENET newsgroup comp.std.unix is also known as the ARPA Internet
mailing list std-unix@uunet.uu.net. It is for discussions of
UNIX standards, particularly the IEEE 1003.1 POSIX Trial Use Standard.
The moderator is John S. Quarterman, who is also the institutional
representative of the USENIX Association to the IEEE P1003 Portable
Operating System for Computer Environments Committee (commonly known
as the UNIX Standards Committee).
Submissions-To: uunet!std-unix or std-unix@uunet.uu.net
Comments-To: uunet!std-unix-request or std-unix-request@uunet.uu.net
The former addresses through sally.utexas.edu or ut-sally still work.
Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail. Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.
Archives may be found on uunet.uu.net. The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
over the ARPA Internet as
~ftp/comp.std.unix/archive
or
~ftp/comp.std.unix/volume.12
The previous volume may be retrieved as
~ftp/comp.std.unix/volume.11
For hosts with direct UUCP connections to the uunet machine,
UUCP retrieval should work with, for example,
/usr/spool/uucppublic/ftp/comp.std.unix/archive
Volumes 1-10 are filed under the old newsgroup name, mod.std.unix,
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc., through
~ftp/pub/mod.std.unix.v10. Volume 3 contains the AT&T public domain
getopt(3). Volume 10 is a special index volume that catalogs Volumes 1-9.
These volumes are strictly for administrative convenience.
Paper copies of them get delivered to the P1003 committee chair
from time to time and several members of the committee follow
the newsgroup on-line.
Also, paper copies will soon be available from the office of the
USENIX Association, in support of the Institutional Representative
from USENIX to the IEEE P1003 committee. Selection will be by
whole volumes only, not by specific articles. This service will
be available when sufficient disk space is added to USENIX equipment
in the next few months.
USENIX Association
P.O. Box 2299
Berkeley, CA 94710
415-528-8649
{ucbvax,uunet}!usenix!office
The archives have been somewhat cleaned up in the process of indexing
them. Irrelevant mail headers have been deleted and "From " (not "From:")
lines in text articles have been escaped or removed to avoid confusing
mail reading programs. An extra header, "Draft-9:", has been added to
contain the index references by section of 1003.1 Draft 9 or related
topic. It is hoped that these changes, together with the access
information in Volume 10, will make the archives more useful.
Finally, remember that any remarks by any committee member (especially
including me) in this newsgroup do not represent any position (including
any draft, proposed or actual, of a standard) of the committee as a
whole or of any subcommittee unless explicitly stated otherwise
in such remarks.
UNIX is a Registered Trademark of AT&T.
POSIX is a Trademark of IEEE.
IEEE is a Trademark of the Institute of Electrical and Electronics
Engineers, Inc.
PS: If this article was garbled in transmission to you, that probably
means it passed through a host still running B news 2.10, which doesn't
understand moderated newsgroup names that don't start with "mod.".
You should examine the Path: header, try to determine which host it is,
and ask them to upgrade to 2.11.
Volume-Number: Volume 12, Number 1
From jsq Sat Jul 18 14:07:42 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA14110; Sat, 18 Jul 87 14:07:42 EDT
From: std-unix%uunet.UUCP%@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <669@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: std-unix@uunet.UU.NET (Moderator, John Quarterman)
Date: 18 Jul 87 18:07:32 GMT
Apparently-To: std-unix-archive
This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.
Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
1003.3 (testing and verification), 1003.4 (real time).
/usr/group working groups on distributed file system, network interface,
graphics/windows, database, internationalization,
performance measurements, realtime, security, and super computing
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals
UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.
The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They published the 1003.1 "POSIX" Trial Use Standard in April 1986.
According to its Foreword:
The purpose of this document is to define a standard
operating system interface and environment based on the
UNIX Operating System documentation to support application
portability at the source level. This is intended for
systems implementors and applications software developers.
Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles
714-821-8380
and ask for Book #967. Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:
IEEE Computer Society
P.O. Box 80452
Worldway Postal Center
Los Angeles, Ca. 90080
Include a check for $19.95 + $4 for shipping and handling. For UPS
shipping, add another $4. Or contact:
IEEE Service Center
445 Hoes Ln.
Piscataway, NJ 08854
and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.
The Trial Use Standard will be available for comments for a period
such as a year. The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.
Machine readable copies of the Trial Use Standard are not and will
not be available.
There is a paper mailing list by which interested parties may get
copies of drafts of the standard. To get on it, or to submit comments
directly to the committee, mail to:
James Isaak
Chairperson, IEEE/CS P1003
Digital Equipment MK02-2/B05
Continental Blvd.
Merrimack, NH 03054-0403
decvax!isaak
603-884-1913
Sufficiently interested parties may join the working group.
Related working groups are
group subject co-chairs
1003.2 shell and tools Hal Jespersen (UniSoft), Don Cragun (Sun)
1003.3 verification Roger Martin (NBS), Carol Raye (AT&T)
1003.4 real time Bill Corwin (Intel)
Inquiries regarding 1003.2, 1003.3, and 1003.4 should go to the same address
as for 1003.1.
The next scheduled meetings of the P1003 working groups are,
in 1987 and 1988:
Sept. 14-18 Framingham, Massachusetts (same time and place as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)
Dec. 7-11 San Diego
April 1988 Washington, D.C.
There is also a balloting group (which intersects with the working group).
This is more difficult. Contact Jim Isaak for details. I will repost
them in this newsgroup if there is sufficient interest.
Here are some details from Hal Jespersen regarding P1003.2:
The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard. It will
consist of
a shell command language (currently planned to be based on the
Bourne Shell),
groups of utility programs, or commands,
programmatic interfaces to the shell (system(), popen()) and
related facilities (regular expressions, file name expansion,
etc.)
defined environments (variables, file hierarchies, etc) that
applications may rely upon
tools for installing application programs onto conforming
systems
which will allow application programs to be developed out of existing
pieces, in the UNIX tradition. The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.
There has been some controversy in the Working Group about
clarifying the scope of the 1003.2 standard in regard to its
relationship with 1003.1. The Working Group is attempting to
produce a standard that will assume the structure and
philosophy of a POSIX system is available, but it will not
require a fully conforming implementation as a base. For
example, it should be feasible to eventually produce a 1003.2
interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and
utilities didn't need them). However, the proposed standard
will *not* be unnecessarily watered down simply to allow
non-POSIX systems to conform.
The group is currently seeking proposals for groupings of commands that
may be offered by implementors. As groups are identified, command
descriptions will be solicited. There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.
There are three Institutional Representatives to P1003: John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Martha Nalebuf from X/OPEN.
As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee. One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
(formerly known as mod.std.unix). An article related to this one
appeared in the September/October 1986 ;login: (The USENIX Association
Newsletter). I'm also currently on the USENIX Board of Directors.
Comments, suggestions, etc., may be sent to
John S. Quarterman
Texas Internet Consulting
701 Brazos, Suite 500
Austin TX 78701-3243
+1-512-320-9031
usenix!jsq
For comp.std.unix:
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
The May/June 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in January 1987.
If you are interested in starting another working group, contact
Heinz Lycklama:
Heinz Lycklama
Interactive Systems Corp.
2401 Colorado Ave., 3rd Floor
Santa Monica, CA 90404
(213)453-8649
decvax!cca!ima!heinz
Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above, and updated by later information
from Heinz Lycklama.
/usr/group Working Group on Distributed File System:
Laurence Brown Frederick Glover
AT&T Information Systems MK02-1/H10
190 River Road Digital Equipment Corporation
Summit, NJ 07933 Continental Boulevard
201-522-6046 Merrimack, NH 03054-0430
attunix!bump 603-884-5111
decvax!fglover
/usr/group Working Group on Network Interface:
Steve Albert
AT&T Information Systems
190 River Road, Rm. A-114
Summit, NJ 07901
(201)522-6104
attunix!ssa
/usr/group Working Group on Internationalization:
Karen Barnes
Hewlett-Packard Co.
19447 Pruneridge Ave.
M/S 47U2
Cupertino, CA 95014
(408) 447-6704
/usr/group Working Group on Graphics/Windows:
Tom Greene
Apollo Computer, Inc.
330 Billerica Road
Chelmsford, MA 01824
(617)256-6600, ext. 7581
/usr/group Working Group on Realtime:
Bill Corwin
Intel Corp.
5200 Elam Young Pkwy
Hillsboro, OR 97123
(503)681-2248
/usr/group Working Group on Database:
Val Skalabrin
Unify Corp.
1111 Howe Ave.
Sacramento, CA 95825
(916)920-9092
/usr/group Working Group on Performance Measurements:
Ram Chelluri Dave Hinnant
AT&T Computer Systems SCI Systems, Inc.
Room E15B Ste 325, Pamlico Bldg
4513 Western Ave. Research Triangle Pk, NC 27709
Lisle, IL 60532 (919)549-8334
(312)810-6223
/usr/group Working Group on Security:
Steve Sutton Ms. Jeanne Baccash
Consultant, Addamax AT&T UNIX Systems Engineering
1107 S. Orchard 190 River Road
Urbana, IL 61801 Summit, NJ 07901
217-344-0996 201-522-6028
attunix!jeanne
/usr/group Working Group on Super Computing:
Karen Sheaffer Robin O'Neill
Sandia National Laboratory Lawrence Livermore Laboratory
P.O. Box 969 P.O. Box 5509, L560
Livermore, CA 94550 Livermore, CA 94550
415-422-3431 415-422-0973
oneill#r%mfe@lll-mfe.arpa Co-chair
The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system. The chair solicits
help and participation:
Georges Grinstein
wanginst!ulowell!grinstein
The Abstract of the 1003.1 Trial Use Standard adds:
This interface is a complement to the C Programming Language
in the C Information Bulletin prepared by Technical Committee X3J11
of the Accredited Standards Committee X3, Information Processing
Systems, further specifying an environment for portable application
software.
X3J11 is sometimes known as the C Standards Committee. Their liaison to
P1003 is
Don Kretsch
AT&T
190 River Road
Summit, NJ 07901
A contact for information regarding publications and working groups is
Thomas Plum
Vice Chair, X3J11 Committee
Plum Hall Inc.
1 Spruce Avenue
Cardiff, New Jersey 08232
The current document may be ordered from
Global Press
2625 Hickory St.
P.O. Box 2504
Santa Anna, CA 92707-3783
U.S.A.
800-854-7179
+1-714-540-9870 (from outside the U.S., ask for extension 245.)
TELEX 692 373
Ask for the X3.159 draft standard. The price is $65.
The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11. It may be ordered for $15.00 from:
/usr/group Standards Committee
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
(408)986-8840
The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.
AT&T Customer Information Center
Attn: Customer Service Representative
P.O. Box 19901
Indianapolis, IN 46219
U.S.A.
800-432-6600 (Inside U.S.A.)
800-255-1242 (Inside Canada)
317-352-8557 (Outside U.S.A. and Canada)
System V Interface Definition, Issue 2
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-011 Volume I Base System
Kernel Extension
320-012 Volume II Basic Utilities Extension
Advanced Utilities Extension
Software Development Extension
Administered System Extension
Terminal Volume Interface Extension
320-013 Volume III Base System Addendum
Terminal Interface Extension
Network Services Extension
307-131 I, II, III (all three volumes)
The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders: mail orders
should include a check or money order, payable to AT&T.
The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.
The X/OPEN Group is "Ten of the world's major information system
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL,
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have
produced a document intended to promote the writing of portable
facilities. They closely follow both SVID and POSIX, and cite
the /usr/group standard as contributing, but X/OPEN's books
cover a wider area than any of those.
The book is published by
Elsevier Science Publishers B.V.
Book Order Department
P.O. Box 1991
1000 BZ Amsterdam
The Netherlands
and distributed in the U.S.A. and Canada by:
Elsevier Science Publishing Company, Inc.
52 Vanderbilt Avenue
New York, NY 10017
U.S.A.
There are currently five volumes:
1) System V Specification Commands and Utilities
2) System V Specification System Calls and Libraries
3) System V Specification Supplementary Definitions
4) Programming Languages
5) Data Management
They take a large number of credit cards and other forms of payment.
Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:
Howard Press
c/o USENIX Association
P.O. Box 2299
Berkeley, CA 94710
415-528-8649
{ucbvax,decvax}!usenix!office
4.3BSD User's Manual Set (3 volumes) $25.00
User's Reference Manual
User's Supplementary Documents
Master Index
4.3BSD Programmer's Manual Set (3 volumes) $25.00
Programmer's Reference Maual
Programmer's Supplementary Documents, Volume 1
Programmer's Supplementary Documents, Volume 2
4.3BSD System Manager's Manual (1 volume) $10.00
Unfortunately, there are some license restrictions.
Contact the USENIX office for details.
Volume-Number: Volume 12, Number 2
From jsq Thu Aug 6 01:58:06 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA13463; Thu, 6 Aug 87 01:58:06 EDT
From: Jim Joyce <jim%hoptoad.UUCP@uunet.UU.NET>
Newsgroups: comp.std.unix
Subject: Jim Joyce's UNIX Bookstore
Message-Id: <771@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: hoptoad!jim (Jim Joyce)
Date: 23 Jul 87 02:18:25 GMT
Apparently-To: std-unix-archive
From: jim@hoptoad.UUCP (Jim Joyce)
Jim Joyce's UNIX Bookstore is a phone- e-mail- and mail-order bookstore
specializing in items regarding UNIX and the C programming language.
Jim Joyce writes mini-reviews of all the books carried,
which are available in his Bookstore Catalog.
There are also Reading Lists on various topics:
1) C Programmers [new to UNIX and C],
2) System Administration,
3) Shell Programming.
Other Reading Lists to come soon:
1) UNIX Internals,
2) UNIX Document Formatting,
3) UNIX for Non-Programmers.
Discounts available for corporate accounts.
Volume-Number: Volume 12, Number 3
From jsq Thu Aug 6 01:59:39 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA13503; Thu, 6 Aug 87 01:59:39 EDT
From: Karen Paszamant <ajr%hjuxa.UUCP@uunet.UU.NET>
Newsgroups: comp.std.unix
Subject: rfs on 4.2 bsd
Message-Id: <772@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: hjuxa!ajr (Karen Paszamant)
Organization: Digital Equipment Corp. Holmdel, NJ
Date: 6 Aug 87 05:59:30 GMT
Apparently-To: std-unix-archive
From: ajr@hjuxa.UUCP (Karen Paszamant)
I understand there is an RFS that is supported on 4.2 BSD.
does anyone have it up and running? What kind of environment is it
in? How bug free is the version that your running? Whose software
is it? Is it public domain?
I would appreciate any information.
Thanks
Adrienne Reskof
hjuxa!ajr
Volume-Number: Volume 12, Number 4
From jsq Mon Aug 10 23:50:29 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA11969; Mon, 10 Aug 87 23:50:29 EDT
From: John Gilmore <gnu%hoptoad.UUCP@uunet.UU.NET>
Newsgroups: comp.std.unix
Subject: Changed names in POSIX directory access library
Message-Id: <842@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: hoptoad!gnu (John Gilmore)
Date: 8 Aug 87 09:58:30 GMT
Apparently-To: std-unix-archive
Cc: gwyn@brl.arpa, utzoo.UUCP!henry@cgl.ucsf.edu
From: gnu@hoptoad.UUCP (John Gilmore)
I just ran across the first use of the Posix directory access library
and was disappointed that it is not source-code compatible with the
Unix BSD library, or with the public domain directory access library
that has been widely used on non-BSD systems.
For some reason the ***&%^$ standard changed the names of the include
file and the struct!
The old #include <sys/dir.h> is now #include <dirent.h>
" struct direct struct dirent
My problem arose when Richard Todd ported my PD tar to Minix. This
tar program has been ported and run on many, many Unix variants. All
these versions compile from the same sources. Minix lacks a directory
access library (and a lot of other library routines), so Richard used
the package posted to mod.sources by Doug Gwyn. Unfortunately, it's
not compatible with Unix, and I wouldn't change tar; I'd rather have it
break on Richard's modified Minix than break on every Unix in existence.
So his Minix tar sources must remain slightly different from the master,
portable sources I keep.
Somehow when you read these standards on paper, they don't mean much.
When people implement it and your 'proven portable' programs break, the
little meddling changes get a lot more important.
>From the NOTES file in Doug's package:
>One annoying compatibility problem has arisen along the way, namely that the
>original Berkeley interface used the same name, struct direct, for the new data
>structure as had been used for the original UNIX filesystem directory record
>structure. This name was changed by the IEEE 1003.1 (POSIX) Working Group to
>"struct dirent" and was picked up for SVR3 under the new name; it is also the
>name used in this portable package. I believe it is necessary to bite the
>bullet and adopt the new non-conflicting name. Code using a 4.2BSD-compatible
>package needs to be slightly revised to work with this new package...
Why POSIX changed it I'll probably never know, but it's clear why SVR3
adopted the change. They have been resisting incorporating the
directory library for years and years, apparently because it was a good
idea. When POSIX mangled it, AT&T jumped at the chance to adopt a
version incompatible with all the code written for BSD Unix. So call
me a cynic.
No portable application program should be including a struct defining
the internal format of old Unix file system entries, so I can't see any
theoretical problem created by using the name "struct direct" for the
result of Posix readdir(). There is certainly no practical problem
with it either, since we have been doing it for the last 5 years.
I'm curious why Doug thinks "it is necessary to bite the bullet". How about
the obvious alternative of changing the standard to match all existing
applications?
Volume-Number: Volume 12, Number 5
From jsq Mon Aug 10 23:58:28 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA12070; Mon, 10 Aug 87 23:58:28 EDT
From: (VLD/VMB <gwyn@brl.arpa>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <843@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>
Date: 8 Aug 87 14:52:48 GMT
Apparently-To: std-unix-archive
To: John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.edu>
Cc: std-unix@sally.utexas.edu, utzoo.UUCP!henry@cgl.ucsf.edu
From: Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>
I explained what the problem was with McKusick's implementation
and why both AT&T and IEEE 1003.1 decided to do it differently.
I also provided a public-domain package that can be built for
use on Berkeley-based systems, so the POSIX interface is
available there, too. However, it is simply not practical for
most vendors to provide the Berkeley interface in a true System
V environment (more on this later).
You keep making noises that sound like you think there is a
conspiracy to reject correct Berkeley designs for various things
in favor of inferior approaches. I've been at least peripherally
involved with almost all those situations, and that simply is not
what happens. The real problem is that Berkeley keeps coming
out with stuff that has design or compatibility problems that
other people have to figure out how to fix later. Such fixes
are not gratuitous changes to perfect designs!
You probably don't notice the problems because you work in a
Berkeley-based environment. Try building some of your code on
real SVR2 systems some time and see what you break when you
change SVR2 to use the Berkeley <sys/dir.h> -- your code would
then work but there are a LOT of existing programs affected by
that incompatible change. Real-world vendors have to accommodate
existing (pre-BFS/NFS) code that did the best it could under
prevailing circumstances while providing improved, portable
support for future applications.
I ran head-on into this directory issue when I ported UNIX
System V (user mode) onto 4.2BSD. My solution was to throw out
<sys/dir.h> altogether, and provide (McKusick-compatible)
directory access functions for the System V environment. The
reason I could do that was that I was in total charge of all
software to run in that environment. When we started importing
code, the absence of <sys/dir.h> is the only thing that saved us
from wasting valuable time tracking down obscure bugs. Vendors
that might have tried such an approach would have upset their
existing customer base.
My older package served as the basis for the one in SVR3, which
was modified by AT&T to conform to POSIX, which by then had
already identified the problem with using <sys/dir.h> and/or
(struct dirent) for the portable directory interface. I fully
support the POSIX choice of names as a correct decision.
Until we get 4.4BSD (or whatever) into POSIX compliance, simply
build my PD package for BFS and use it with your portable code.
Volume-Number: Volume 12, Number 6
From jsq Tue Aug 11 00:06:44 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA12162; Tue, 11 Aug 87 00:06:44 EDT
From: <utzoo!henry>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <844@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: utzoo!henry
Date: 9 Aug 87 09:28:52 GMT
Apparently-To: std-unix-archive
Cc: std-unix@sally.utexas.edu
Cc: gwyn@brl.arpa
From: henry@utzoo.uucp
> I just ran across the first use of the Posix directory access library
> and was disappointed that it is not source-code compatible...
>
> For some reason the ***&%^$ standard changed the names of the include
> file and the struct!
For an excellent reason: Berkeley's imbecilic decision to use the same
names in the high-level library as in the implementation within the
kernel causes endless trouble on non-Berkeley systems.
> The old #include <sys/dir.h> is now #include <dirent.h>
This is a godsend for those of us who have a *different* directory structure
in our sys/dir.h, namely that used in the kernel. User-level libraries
have no business parking their include files in the sys subdirectory!
> " struct direct struct dirent
And this is a godsend for those of us who want to include *other* kernel
include files in the same program as the directory library. The kernel
include files are so interrelated that it is impossible to pick up, say,
user.h without also picking up dir.h. Which means that no program that
uses any of the kernel include files can use the directory library, because
the definitions of "struct direct" clash. Yes, there are legitimate reasons
for using some of the other include files, at least in non-Berkeley systems.
Arguably these reasons themselves indicate problems that really ought to be
fixed -- but we were talking about compatibility with existing practice!
In short, I can assure John that there *are* practical problems with using
the Berkeley naming on non-Berkeley systems. I have run into them too
often myself to do anything but applaud this "incompatibility"; non-Berklix
systems already find it necessary to engage in incompatible kludges to use
the otherwise-praiseworthy directory library. I am one of the (doubtless
numerous) people who strongly urged P1003 to fix this bug.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
Volume-Number: Volume 12, Number 7
From jsq Tue Aug 11 00:19:03 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA12338; Tue, 11 Aug 87 00:19:03 EDT
From: John S. Quarterman <jsq@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <845@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: jsq@longway.tic.com (John S. Quarterman)
Date: 9 Aug 87 18:16:16 GMT
Apparently-To: std-unix-archive
To: gnu@sun.com, sun.com!utzoo!henry@uunet.UU.NET
Cc: gwyn@BRL.ARPA, std-unix@sally.utexas.edu
From: jsq@longway.tic.com (John S. Quarterman)
I'd like to remind all of you to avoid words like ``imbecilic.''
I'm interested in posting technical discussions, not ad-hominem attacks.
That said, mea culpa, mea max culpa for not getting the real
reason for the name change into the POSIX Rationale.
Volume-Number: Volume 12, Number 8
From jsq Wed Aug 12 01:00:06 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA18041; Wed, 12 Aug 87 01:00:06 EDT
From: Kirk McKusick <mckusick%okeeffe@berkeley.edu>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <870@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: mckusick%okeeffe@berkeley.edu (Kirk McKusick)
Date: 11 Aug 87 19:33:34 GMT
Apparently-To: std-unix-archive
Cc: hoptoad!gnu@cgl.ucsf.edu (John Gilmore), gwyn@brl.arpa (Doug Gwyn),
utzoo!henry@sun.com (Henry Spencer),
longway!jsq@uunet.UU.NET (John S. Quarterman),
karels@okeeffe.berkeley.edu (Mike Karels)
From: mckusick%okeeffe@berkeley.edu (Kirk McKusick)
When I wrote the directory access routines I made a mistake in
connecting them with the underlying implementation of the file
system. They clearly should work on an abstract directory
definition which may coincidentally be the same as the underlying
directory structure (as it is in 4.3BSD). As such, I fully agree
with the decision in the POSIX standard to create a new header
file <dirent.h> rather than using <sys/dir.h>. It is the intention
of CSRG to change the source code at Berkeley to <dirent.h>.
I do take exception to the apparently gratuitous change of renaming
`d_ino' to `d_fileno' in the System V interface, though this can be
worked around with a #define.
Kirk McKusick
mckusick@berkeley.edu
ucbvax!mckusick
Volume-Number: Volume 12, Number 9
From jsq Thu Aug 13 00:19:55 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA12483; Thu, 13 Aug 87 00:19:55 EDT
From: Jim R Oldroyd <mcvax!inset!jr@seismo.css.gov>
Newsgroups: comp.std.unix
Subject: Benefits of CPIO over TAR
Message-Id: <890@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: Jim R Oldroyd <mcvax!inset!jr@seismo.css.gov>
Organization: The Instruction Set Ltd.
Date: 13 Aug 87 04:19:46 GMT
Apparently-To: std-unix-archive
Phone: +44 1 251 2128
Telex: 295467 inset g
From: Jim R Oldroyd <mcvax!inset!jr@seismo.css.gov>
[ This has been a bit delayed due to miscommunication. -mod ]
I would like to present a number of points regarding CPIO which I
feel are relevant to the ongoing discussion concerning a Data
Interchange Format for the POSIX 1003.1 standard.
I shall correct a number of important points regarding the CPIO
format; points which have been incorrectly stated in recent articles.
1. At no time has a proposal been made to standardise the binary
cpio format. Only the `cpio -c' format is under consideration.
2. The `cpio -c' format is widely in use in Europe for both Data
Interchange and Archival purposes. It's widespread use can
be attributed, in part, to its endorsement by the X/OPEN Group.
3. Only one version of the `cpio -c' format is currently in use.
It is this format being proposed for standardisation.
4. The `cpio -c' header is written entirely in character form.
No numerical information is stored in machine-dependent binary
form.
5. The `cpio -c' format is capable of archiving and restoring
all POSIX file types: directories, block special files,
character special files, regular files and fifos.
6. The `cpio -c' format can handle pathnames up to 256 bytes.
This is the length guaranteed on all POSIX systems.
7. The `cpio -c' format is in the public domain. (See X/OPEN
Portability Guide, Volume 2, cpio(4)).
8. Inode numbers are not recorded. Symbolic values (derived from a
file's inode and device numbers) are stored in the header
block. These values are used solely for hard link resolution.
9. File types are stored in symbolic form. Symbols are derived from
historical UNIX file type values. There is room for 64
file types; currently only 5 are supported.
A number of points have recently been raised as drawbacks of CPIO.
These points seem to be problems with a particular implementation
of a cpio utility. As the characteristics of the utility are not
relevant for 1003.1, I present only a short summary of points:
- file names are terminated by '\0'
This is normal UNIX practice for string termination
and applies to TAR (and USTAR) equally. On CPIO,
the '\0' is redundant information and need not
be interpreted as the file name length is also provided.
- the user interface is less convenient
This is subjective; many people feel that the
opposite is true. The user interface is easily
alterable (discuss with 1003.2).
- file name size is 128 bytes
Wrong! It is 256; see above.
- cpio header is full of OS dependent information
Wrong! All information describes file
characteristics. There is no OS dependent
information. See point 9, above.
- header must start on a word boundary
Wrong! The header is character oriented and
can be read as individual bytes from the archive.
- format cannot be extended to meet future requirements
Wrong! Implementations already exist which can
archive symbolic links and contiguous files.
There is far more scope for future extension
than available in the proposed USTAR format.
Independent of the archive format used, some guidelines must
be followed to ensure that an archive can be extracted on ANY
POSIX system. Note that the following are NOT rules for using
cpio; they apply equally well to other interchange formats
if portability across ALL systems is to be achieved:
- only POSIX defined file types should be archived
- headers should be written in US ASCII character set
- minumum values in section 2.9 for h_uid, h_gid,
h_nlinks, etc should not be exceeded
- no portion of any filename should exceed 14 characters
- one cpio archive should fit on a single medium
- only one archive should exist per medium
- relative pathnames (ie, no leading /) should be used
- tapes should be written in `raw' mode
- tapes should be written with 5120 byte blocks
Any archive intended for use only between systems supporting
more capabilities than the minimum required by POSIX need
not be so restrictive.
I believe that the `cpio -c' tape format has a number of strong
advantages over both the existing tar and the POSIX extended tar
formats. The `cpio -c' format handles all POSIX file types
correctly, it has been extended to handle other known file types
and there is adequate opportunity for further extension.
Thank you,
Jim R Oldroyd.
Volume-Number: Volume 12, Number 10
From jsq Thu Aug 13 22:37:35 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA10079; Thu, 13 Aug 87 22:37:35 EDT
From: Guy Harris <guy@Sun.COM>
Newsgroups: comp.std.unix
Subject: Re: Benefits of CPIO over TAR
Message-Id: <904@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: guy@Sun.COM (Guy Harris)
Date: 13 Aug 87 09:55:10 GMT
Apparently-To: std-unix-archive
From: uunet!Sun.COM!guy (Guy Harris)
> 1. At no time has a proposal been made to standardise the binary
> cpio format. Only the `cpio -c' format is under consideration.
A proposal was made by Lorraine Kevra of AT&T to standardize both the binary
and character "cpio" format. Fortunately, this proposal appears to have been
dropped in favor of a character-format-only proposal.
> 2. The `cpio -c' format is widely in use in Europe for both Data
> Interchange and Archival purposes. It's widespread use can
> be attributed, in part, to its endorsement by the X/OPEN Group.
Both the "tar" and "cpio -c" format are in wide use throughout the world. The
major commonly available UNIX source distributions all include implementations
of "tar", but not all of them include implementations of "cpio".
> 8. Inode numbers are not recorded. Symbolic values (derived from a
> file's inode and device numbers) are stored in the header
> block. These values are used solely for hard link resolution.
> 9. File types are stored in symbolic form. Symbols are derived from
> historical UNIX file type values. There is room for 64
> file types; currently only 5 are supported.
The proposal does not match what is stated in the X/OPEN Portability Guide
(January 1987). In Volume 2, section "File Formats", under CPIO(4), it states:
When the "-c" option of "cpio(1)" is used, the header information is
described by:
printf or scanf(<big string>, <list of arguments>);
...The meanings of the items "h_dev" through "h_mtime" are explained in
"stat(2)".
The items in question include "h_dev", "h_ino", and "h_mode".
Under "stat(2)", those fields are given their customary UNIX meanings.
I presume X/OPEN plans to alter CPIO(4) to reflect the fact that "h_dev",
"h_ino", and "h_mode" are no longer directly connected to the "st_dev",
"st_ino", and "st_mode" fields of the "stat" structure.
> - format cannot be extended to meet future requirements
> Wrong! Implementations already exist which can
> archive symbolic links and contiguous files.
> There is far more scope for future extension
> than available in the proposed USTAR format.
Could you please indicate how this is the case?
Volume-Number: Volume 12, Number 11
From jsq Fri Aug 14 00:04:32 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA11237; Fri, 14 Aug 87 00:04:32 EDT
From: std-unix@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: cpio
Message-Id: <906@uunet.UU.NET>
Reply-To: attunix!kevra (Lorraine Kevra)
Date: 14 Aug 87 04:04:24 GMT
Apparently-To: std-unix-archive
From: attunix!kevra (Lorraine Kevra)
[ This is the current cpio proposal for 1003.1 -mod ]
FOR COMPUTER ENVIRONMENTS Std 1003.1-Draft 11
Editor's Note: The following section has been proposed as a b
replacement for, or an addition to, the previous section. b
The small group that considered the issue at the June 1987 b
meeting determined that indications were needed on how to b
extend this subsection to account for at least the following b
items: b
o+ symbolic links b
o+ contiguous files b
o+ file name length b
o+ i-node number size b
There is a possibility that these concerns may be addressed b
by text in the Rationale, rather than in the body of the b
standard. b
10.3.1 cpio Archive Format b
The byte-oriented cpio archive format is a series of b
entries, each comprised of a header that describes the file, b
the name of the file, and then the contents of the file. b
An archive may be recorded as a series of fixed size blocks b
of bytes. This blocking shall be used only to make physical b
I/O more efficient. The last group of blocks is always at b
the full size. b
For the byte-oriented cpio archive format, the individual b
entry information must be in the order indicated and is b
described by: b
UNAPPROVED DRAFT. All Rights Reserved by IEEE.
Do not specify or claim conformance to this document.
Std 1003.1-Draft 11 PORTABLE OPERATING SYSTEM
Byte-Oriented cpio Archive Entry b
Header b
Field Name Length Interpreted as b
__________ __________ _______________ b
c_magic 6 bytes octal number b
c_dev 6 bytes octal number b
c_ino 6 bytes octal number b
c_mode 6 bytes octal number b
c_uid 6 bytes octal number b
c_gid 6 bytes octal number b
c_nlink 6 bytes octal number b
c_rdev 6 bytes octal number b
c_mtime 11 bytes octal number b
c_namesize 6 bytes octal number b
c_filesize 11 bytes octal number b
File Name b
Field Name Length Interpreted as b
__________ __________ _______________ b
c_name c_namesize pathname string b
File Data b
Field Name Length Interpreted as b
__________ __________ _______________ b
c_filedata c_filesize data b
22 10.3.1.1 Header b
23 For each file in the archive, a header as defined above b
24 shall be written. The information in the header fields b
25 shall be written as streams of bytes interpreted as octal b
26 numbers and shall be right-justified and zero filled. The b
27 fields shall be interpreted as follows: b
28 o+ c_magic shall identify the archive as being a b
29 transportable archive by containing the magic bytes as b
30 defined by MAGIC ("070707"). b
31 o+ c_dev and c_ino shall contain values which uniquely b
32 identify the file within the archive (i.e., no files b
33 shall contain the same pair of c_dev and c_ino values b
34 unless they are links to the same file). The values b
35 shall be determined in an implementation defined b
36 manner. b
37 o+ c_mode shall contain the file type and access b
38 permissions as defined in the tables below. b
UNAPPROVED DRAFT. All Rights Reserved by IEEE.
Do not specify or claim conformance to this document.
FOR COMPUTER ENVIRONMENTS Std 1003.1-Draft 11
39 o+ c_uid shall contain the user id of the owner. b
40 o+ c_gid shall contain the group id of the group. b
41 o+ c_nlink shall contain the number of links referencing b
42 the file at the time the archive was created. b
43 o+ c_rdev shall contain implementation defined information b
44 for character or block special files. b
45 o+ c_mtime shall contain the latest time of modification b
46 of the file. b
47 o+ c_namesize shall contain the length of the path name, b
48 including the terminating null byte. b
49 o+ c_filesize shall contain the length of the file. This b
50 is the length of the data section following the header b
51 structure. b
52 10.3.1.2 File Name b
53 c_name shall contain the path name of the file. The length b
54 of the name is determined by c_namesize; the maximum length b
55 of this string is 256 bytes. b
56 10.3.1.3 File Data b
57 Following c_name, there shall be c_filesize bytes of data. b
58 Interpretation of such data shall occur in a manner b
59 dependent on the file. If c_filesize is zero, no data shall b
60 be contained in c_filedata. b
61 10.3.1.4 Special Entries b
62 Special files, directories, and the trailer are recorded b
63 with c_filesize equal to zero. The header for the next file b
64 entry in the archive shall be written directly after the b
65 last byte of the file entry preceding it. A header denoting b
66 the file name ``TRAILER!!!'' shall indicate the end of the b
67 archive; the contents of bytes in the last block of the b
68 archive following such a header are undefined. b
69 10.3.1.5 cpio Values b
70 Values needed by the cpio archive format are described as b
71 follows: b
UNAPPROVED DRAFT. All Rights Reserved by IEEE.
Do not specify or claim conformance to this document.
Std 1003.1-Draft 11 PORTABLE OPERATING SYSTEM
Values for c_mode field b
File permissions b
Name Value Indicates b
_______ ______ __________________ b
C_IRUSR 000400 read by owner b
C_IWUSR 000200 write by owner b
C_IXUSR 000100 execute by owner b
C_IRGRP 000040 read by group b
C_IWGRP 000020 write by group b
C_IXGRP 000010 execute by group b
C_IROTH 000004 read by others b
C_IWOTH 000002 write by others b
C_IXOTH 000001 execute by others b
C_ISUID 004000 set uid b
C_ISGID 002000 set gid b
C_ISVTX 001000 reserved b
Values for c_mode field b
File type b
Name Value Indicates b
________ ______ _________________ b
C_ISDIR 040000 directory b
C_ISFIFO 010000 FIFO b
C_ISREG 100000 regular file b
C_ISBLK 060000 block special b
C_ISCHR 020000 character special b
110000 reserved b
120000 reserved b
140000 reserved b
101 C_ISDIR, C_ISFIFO, and C_ISREG shall be supported on a POSIX b
102 conforming system; additional values defined above are b
103 reserved for compatibility with existing systems. b
104 Additional file types may be supported; however, such files b
105 should not be written on archives intended for transport to b
106 portable systems. b
107 10.3.1.6 References b
108 <grp.h> sS9.2.1, <pwd.h> sS9.2.2, <sys/stat.h> sS5.6.1, chmod() b
109 sS5.6.4, link() sS5.3.4, mkdir() sS5.4.1, read() sS6.4.1, stat() b
110 sS5.6.2.
111
UNAPPROVED DRAFT. All Rights Reserved by IEEE.
Do not specify or claim conformance to this document.
Volume-Number: Volume 12, Number 12
From news Sat Aug 15 09:43:15 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA16628; Sat, 15 Aug 87 09:43:15 EDT
From: Doug Gwyn <gwyn@BRL-SMOKE.ARPA>
Newsgroups: comp.std.unix
Subject: Re: Benefits of CPIO over TAR
Message-Id: <933@uunet.UU.NET>
References: <890@uunet.UU.NET>
Sender: news@uunet.UU.NET
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 13 Aug 87 18:31:55 GMT
Apparently-To: std-unix-archive
From: gwyn@BRL-SMOKE.ARPA (Doug Gwyn )
In article <890@uunet.UU.NET> Jim R Oldroyd <mcvax!inset!jr@seismo.css.gov> writes:
>3. Only one version of the `cpio -c' format is currently in use.
Ahem. Cray changed theirs. Admittedly that was very short-sighted!
>8. Inode numbers are not recorded. Symbolic values (derived from a
> file's inode and device numbers) are stored in the header
> block. These values are used solely for hard link resolution.
Unfortunately, on systems where the cpio fields for this information
are not big enough, one can find that the wrong links are planted
when files are de-archived. This has actually happened to me.
I never did understand what inter-system archive interchange formats
had to do with specification of a portable environment for
applications. You probably couldn't read my 1/4" tape cartridge no
matter what archive format I used on it. This issue seems to be a
waste of time for 1003.1 and I recommend that it be delegated to
another subgroup, preferably 1003.2 which needs to specify the utility
to cope with such archives anyway.
Volume-Number: Volume 12, Number 13
From jsq Sat Aug 15 11:03:21 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA17142; Sat, 15 Aug 87 11:03:21 EDT
From: std-unix@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: std-unix list cleaned up
Message-Id: <935@uunet.UU.NET>
Date: 15 Aug 87 15:03:13 GMT
Apparently-To: std-unix-archive
All outstanding requests to get on the std-unix@uunet.uu.net
mailng list have been taken care of. Some of them were rather
delayed. Sorry about that. Welcome.
Those already on the list had been seeing duplicates of every
message since the list moved to uunet.uu.net. That has been fixed.
(Thanks, Fletcher.)
Submissions: std-unix@uunet.uu.net uunet!std-unix
Comments: std-unix-request@uunet.uu.net uunet!std-unix-request
The uunet machine talks directly to too many machines to list here,
but if you don't know any other UUCP path, try routing through seismo
for the moment.
Volume-Number: Volume 12, Number 14
From news Mon Aug 17 22:55:14 1987
Posted-Date: 18 Aug 87 03:13:59 GMT
Received-Date: Mon, 17 Aug 87 22:55:14 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA22910; Mon, 17 Aug 87 22:55:14 CDT
From: std-unix@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <974@uunet.UU.NET>
Reply-To: std-unix@uunet.uu.net
Date: 18 Aug 87 03:13:59 GMT
Apparently-To: std-unix-archive
This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.
Access information is given in this article for the following:
user groups: USENIX, /usr/group, EUUG, AUUG, DECUS
newsletters: ;login:, CommUNIXations, EUUG, AUUGN
magazines: UNIX REVIEW, UNIX/WORLD
UNIX is a Registered Trademark of AT&T.
USENIX is "The Professional and Technical UNIX(R) Association."
USENIX Association
P.O. Box 2299
Berkeley, CA 94710
415-528-8649
{uunet,ucbvax,decvax}!usenix!office
USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:
Feb 10-12 1988 Registry Hotel, Dallas, TX, concurrent with Uniforum
Jun 21-24 1988 Hilton Hotel, San Francisco, CA
Feb 1- 3 1989 Town and Country Hotel, San Diego, CA
Jun 13-16 1989 Hyatt Regency, Baltimore, MD
Jun 11-15 1990 Marriott Hotel, Anaheim, CA
They also sponsor workshops, such as
Oct 8- 9 1987 Cambridge Marriott, Cambridge, MA
4th USENIX Computer Graphics Workshop
Oct 22-23 1987 Contact Jim McGinness: decvax!jmcg
POSIX Portability Workshop
Nov 1987 Santa Fe, NM Contact Dave Yost:
C++ Workshop {attmail,uunet,usenix}!grand!day
Proceedings for all conferences and workshops are available at
the door and by mail later.
USENIX publishes ";login: The USENIX Association Newsletter"
bimonthly. It is sent free of charge to all their members and
includes technical papers. There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.
They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving
the USENET and UUCP networks, that are of interest and use to
the membership. They distribute tapes of contributed software
and are pursuing expanding that activity.
There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.
/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.
/usr/group
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
tel: 408-986-8840
fax: 408-986-1645
The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.
Feb 8-11 1988 Infomart, Dallas, TX, concurrent with USENIX
Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
Jan 23-26 1990 Washington Hilton, Washington, DC
Jan 22-25 1991 Infomart, Dallas, TX
Jan 21-24 1992 Moscone Center, San Francisco CA (tentative)
They also sponsor a regional show, UniForum D.C.:
Aug 2-4 1988 Washington Hilton Hotel, Washington, D.C.
Aug 1-3 1989 Washington Hilton Hotel, Washington, D.C.
Proceedings for all conferences are available at the shows and later
by mail.
/usr/group publishes "CommUNIXations", a member magazine that featues
articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.
/usr/group also publishes the "UNIX Products Directory," which lists
products and services developed specifically for the UNIX operating system.
"/usr/digest" is also published by /usr/group. This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.
/usr/group has long been deeply involved in UNIX standardization,
having sponsored the "/usr/group 1984 Standard", providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Working Groups
on areas that P1003 has not yet addressed. They have recently produced
an Executive Summary of the POSIX standard and funded production of a
draft of a Rationale and Notes appendix for that standard.
EUUG is the European UNIX systems Users Group.
EUUG secretariat
Owles Hall
Buntingford
Herts SG9 9PL
England
seismo!mcvax!euug
euug@inset.uucp
They have a newsletter and hold two conferences a year.
The next one is in Dublin, Ireland, 21-25 September,
followed by London, England, 11-15 April 1988.
AUUG is the Australian UNIX systems Users Group.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
seismo!munnari!auug
auug@munnari.oz.au
Phone contact can occasionally be made at +61 3 344 5225
AUUG holds biennial conferences, usually of 2 days each.
They publish a newsletter (AUUGN) at a frequency defined
to be every 2 months.
The next meeting is in Sydney, 27-28 August 1987.
The host is by NSWIT, and for more info people should contact
gregw@nswitgould.oz.au, or to submit a paper, bob@basser.cs.su.oz.au
(deadline for Abstracts is July 10).
There are similar groups in other parts of the world, such as Japan and
Korea. If such a group wishes to be included in later versions of this
access list, they should please send me information.
Also, DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) which participates
in its meetings, which are held twice a year.
DECUS U.S. Chapter
219 Boston Post Road, BP02
Marlboro, Massachusetts 01752-1850
617-480-3418
See also the USENET newsgroup comp.org.decus.
The two main general circulation magazines about the UNIX system are
UNIX REVIEW UNIX/WORLD
Miller Freeman Publications Co. Tech Valley Publishing
500 Howard Street 444 Castro St.
San Francisco, CA 94105 Mountain View, CA 94041
415-397-1881 415-940-1500
Volume-Number: Volume 12, Number 15
From news Mon Aug 17 22:56:12 1987
Posted-Date: 18 Aug 87 03:15:54 GMT
Received-Date: Mon, 17 Aug 87 22:56:12 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA22953; Mon, 17 Aug 87 22:56:12 CDT
From: Dan Franklin <dan@wilma.bbn.com>
Newsgroups: comp.std.unix
Subject: why standard tape format needed (was: Benefits of CPIO over TAR)
Message-Id: <975@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: dan@wilma.bbn.com (Dan Franklin)
Date: 18 Aug 87 03:15:54 GMT
Apparently-To: std-unix-archive
From: dan@wilma.bbn.com (Dan Franklin)
In Vol. 12, No. 13, Doug Gwyn makes several good comments about
cpio vs. tar, but then goes on to say:
> I never did understand what inter-system archive interchange formats
> had to do with specification of a portable environment for
> applications...
The most obvious way they relate is that most applications need to be
installed somehow. How should the developer of the application
package it so it can be read by all POSIX systems? If a standard
format, such as tar, is specified, then the developer can produce the
software in that format and have it copied onto the appropriate medium
for distribution to different machines.
Some applications may also want to provide a facility to save their
file state, carry it onto another machine, and bring it back. A
standard format would be useful here too.
> You probably couldn't read my 1/4" tape cartridge no
> matter what archive format I used on it.
Irrelevant, on two counts. First, there are a lot of machines out
there with half-inch tape drives, and they *could* interchange tapes if
the issues being discussed now were resolved. Second, there are (as I
understand it) only two major 1/4" tape formats, and work is underway
to make one of them standard, so in the future I *will* be able to read
your 1/4" tape cartridge--if the POSIX format is standardized.
Regarding 1003.1 vs. 1003.2: although an argument could be made for
pushing this discussion off into that group, I think it would be a bad
idea. The tape format is not the user interface, as this discussion
has emphasized. Keeping the tape format in 1003.1 helps everyone to
remember that fact. Not only may other programs want to use the same
format, but more importantly, for 1003.1 we can ignore the user
interface altogether. Since both the user interface and the tape
format are incendiary subjects, in this way we have some hope of
actually settling at least part of the issue.
Also, if we postpone this discussion to 1003.2 the whole context of our
current discussions will be lost. We will go through the same cycle
all over again. (Does anyone really want to have to keep repeating, when
the 1003.2 discussions begin, "that point was raised in our 1003.1
discussion and we decided that..."?) The only difference will be that
the discussion will get even more muddled than it is now, because
people will jump back and forth between format issues, which are
fundamental and hard to change, and user interface issues, which are
surface issues that are much easier to change over time.
Please, let's try to decide the issue now. We seem to be getting
closer to a resolution; let's not lose our momentum.
Dan Franklin
Volume-Number: Volume 12, Number 16
From news Sat Aug 22 12:08:15 1987
Posted-Date: 22 Aug 87 17:00:18 GMT
Received-Date: Sat, 22 Aug 87 12:08:15 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA03262; Sat, 22 Aug 87 12:08:15 CDT
From: Jim McGinness <jmcg@decvax.dec.com>
Newsgroups: comp.std.unix
Subject: POSIX Portability Workshop
Keywords: POSIX, USENIX, Portability
Message-Id: <1078@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: jmcg@decvax.dec.com (Jim McGinness)
Date: 22 Aug 87 17:00:18 GMT
Apparently-To: std-unix-archive
From: jmcg@decvax.dec.com (Jim McGinness)
Call for Papers
POSIX Portability Workshop
Berkeley Marina Marriott
October 22-23, 1987
This USENIX workshop will bring together system and application
implementors faced with the problems, "challenges," and other
considerations that arise from attempting to make their products
compliant with IEEE Standard 1003. The first day of the workshop
will consist of presentations of brief position papers describing
experiences, dilemmas, and solutions. On the second day it is
planned to form smaller focus groups to brainstorm additional
solutions, dig deeper into specific areas, and attempt to forge
common approaches to some of the dilemmas. Suggestions for topic
areas and position papers include:
C Language Issues Internationalization
Networked/Distributed Implementations Pipes and FIFOs
Timer resolution, ranges Signals
Conformance verification Security concerns
Job control, process groups Limits: documentation and inquiry
Implications for user interfaces Implications for commands
Position papers should be submitted to:
Jim McGinness
Digital Equipment Corporation
Continental Boulevard MK02-1/HIO
Merrimack, NH 03054
(603) 884-5703
decvax!jmcg
jmcg@decvax.DEC.COM
For registration or hotel information, contact:
Judith F. DesHarnais
USENIX Conference Coordinator
PO Box 385
Sunset Beach, CA 90742
(213) 592-3243
usenix!judy
Volume-Number: Volume 12, Number 17
From news Sat Aug 22 12:40:29 1987
Posted-Date: 22 Aug 87 17:03:57 GMT
Received-Date: Sat, 22 Aug 87 12:40:29 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA03554; Sat, 22 Aug 87 12:40:29 CDT
From: Bob Bagwill <bagwill@decuac.dec.com>
Newsgroups: comp.std.unix
Subject: POSIX Workshop
Keywords: POSIX 1003.1 FIPS
Message-Id: <1079@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: bagwill@decuac.dec.com (Bob Bagwill)
Organization: DEC SWS, Landover, MD
Date: 22 Aug 87 17:03:57 GMT
Apparently-To: std-unix-archive
From: bagwill@decuac.dec.com (Bob Bagwill)
Posted for Roger Martin @ NBS
-------------------------------------------------------------------------------
Announcing a Workshop for POSIX
(IEEE Std. 1003.1) System Implementors
The Institute for Computer Sciences and Technology at the Nation-
al Bureau of Standards (NBS) announces a workshop to discuss im-
plementation issues related to the POSIX Standard, which has been
proposed as a Federal Information Processing Standard (FIPS). To
assure compatibility/interoperability, NBS has reviewed and
analyzed the options that are available for implementing the
Standard, and has selected options that will be proposed as part
of the Federal Standard. At the workshop, NBS will present the
proposed specification and participants will be invited to ex-
press their views.
The workshop will be held October 20-21 at a hotel in the
Rockville- Gaithersburg area. Attendance is limited by space re-
quirements and the size of the conference facility; therefore,
registration is on a first come, first served basis with recom-
mended limitation of two participants per company. A registra-
tion fee will be charged for attending the workshop. Partici-
pants are expected to make their own travel arrangements and ac-
commodations. NBS reserves the right to cancel any part of the
workshop.
To register for the workshop, companies may contact: POSIX
Workshop, Attn: Debbie Jackson, National Bureau of Standards,
Building 225, Room B-252, Gaithersburg, MD 20899. Telephone:
301/975-3295.
The registration request must name the company representative(s)
and specify the business address and telephone number for each
participant. An NBS representative will confirm workshop regis-
tration reservations by telephone. For additional information,
contact D. Richard Kuhn, 301/975-3337.
--
-------------------------------------------------------------------------------
Bob Bagwill Are we not men?
UUCP: {decvax,seismo,cbosgd}!decuac!bagwill INET: bagwill@decuac.DEC.COM
Volume-Number: Volume 12, Number 18
From news Sat Aug 22 12:40:44 1987
Posted-Date: 22 Aug 87 17:13:56 GMT
Received-Date: Sat, 22 Aug 87 12:40:44 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA03563; Sat, 22 Aug 87 12:40:44 CDT
From: std-unix@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Two POSIX Workshops?
Keywords: POSIX, USENIX, NBS
Message-Id: <1080@uunet.UU.NET>
Date: 22 Aug 87 17:13:56 GMT
Apparently-To: std-unix-archive
Some of you may wonder why there are two POSIX workshops
back to back on opposite coasts.
The NBS workshop (20-21 October, D.C. area) is actually more of a
presentation, since NBS intends to present the work they've done on
making a POSIX FIPS, and related work. They hope for a somewhat
marketing-oriented attendee list, and for comments on what they have
done and what they are planning to do. According to Roger Martin of NBS.
The USENIX workshop (22-23 October, in Berkeley) is for application and
interface implementors. The idea is to get them to talk to each other
about common approaches in order to produce more uniform implementations,
to discuss difficult problems, to provide feedback to the P1003
Working Group, and also to present work already done. According
to Jim McGinness.
Both "according to"s might better be "as told to jsq" and the
wording is mine, not theirs.
Volume-Number: Volume 12, Number 19
From news Sun Aug 23 21:41:22 1987
Posted-Date: 24 Aug 87 02:22:07 GMT
Received-Date: Sun, 23 Aug 87 21:41:22 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA24377; Sun, 23 Aug 87 21:41:22 CDT
From: std-unix@uunet.UU.NET (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: guest moderator
Message-Id: <1096@uunet.UU.NET>
Date: 24 Aug 87 02:22:07 GMT
Apparently-To: std-unix-archive
Since I'm going to be missing for about six weeks, there will be
a guest moderator during that time. He's Fletcher Mattox, and is
reachable through the usual addresses:
Submissions: std-unix@uunet.uu.net uunet!std-unix
Comments: std-unix-request@uunet.uu.net uunet!std-unix-request
The uunet machine talks to a large part of the known UUCP network, but
if you don't know how to reach it otherwise, try relaying through seismo.
Volume-Number: Volume 12, Number 20
From fletcher Mon Aug 24 19:35:37 1987
Posted-Date: 24 Aug 87 23:24:22 GMT
Received-Date: Mon, 24 Aug 87 19:35:37 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA15769; Mon, 24 Aug 87 19:35:37 CDT
From: John Quarterman <jsq@usenix.uucp>
Newsgroups: comp.std.unix
Subject: cpio format objections
Message-Id: <8832@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: jsq@usenix.uucp (John Quarterman)
Date: 24 Aug 87 23:24:22 GMT
Apparently-To: std-unix-archive
From: jsq@usenix.uucp (John Quarterman)
cpio format objections Page 1 of 2 IEEE P1003.1 N.117
24 August 1987
John S. Quarterman
Institutional Representative from USENIX
usenix!jsq
Secretary, IEEE Standards Board
Attention: P1003 Working Group
345 East 47th St.
New York, NY 10017
Cc: 1003.1 Technical Reviewers
for Section 10: for Rationale:
Stephen Dum Lorraine Kevra Hal Jespersen
tektronix!athena!steved attunix!kevra ucbvax!unisoft!hlj
The USENIX Association ballots no on the test balloting of
IEEE 1003.1 Draft 11, objecting to the proposed inclusion of
cpio format, for the following reasons:
1. The need for extensions for symbolic links and
contiguous files has not been properly addressed.
Although three type codes are reserved, no indication
is given of what they should be used for. This does
not promote the need for those who implement such
extensions to implement them the same way. It is true
that the text of the standard cannot refer to symbolic
links or high performance files, because they are not
defined in the standard. But the USTAR format
indicates the use of its codes for those extensions
both by the name of the code given in the standard,
and by explicit recommendations in the Rationale. The
cpio proposal does neither.
2. The need for implementation-specific extensions that
do not conflict with present or future standard file
types has not been addressed. The USTAR format
addresses the problem by reserving 26 codes for
implementations to use as they see fit. The cpio
proposal does not address the problem at all.
3. The c_ino field of the cpio format is derived from the
UNIX inode number. Many implementations of cpio use
only 16 bits for this number, and thus cannot properly
resolve links noted in cpio archives that use more
bits for this number. Tar and USTAR formats do not
have this problem, because they do not use a number
like this to resolve links. While some USTAR file
types cannot be read by historical tar
implementations, an error will usually be produced.
This cpio problem will cause silent creation of
cpio format objections Page 2 of 2 IEEE P1003.1 N.117
erroneous links, which is worse.
4. There are few, if any, distributions of UNIX systems
that do not include the tar program, which is
compatible with the POSIX USTAR format. There are
many UNIX systems that do not include cpio.
5. There is a public domain implementation of USTAR
format. There is no public domain implementation of
cpio format, with or without extensions.
There should be one data interchange/archive format in IEEE
1003.1.
+ The proposed cpio format is technically inferior to
USTAR format.
+ The program that cpio format is based on is not as
widely available as the one that USTAR format is based
on, and the same is true of the proposed cpio format
and of USTAR format, respectively.
Therefore, the one format in the standard should be USTAR.
Specific action: deny the cpio format proposal, and do not
include in the standard any references to that format or to
cpio.
Thank you,
John S. Quarterman
Texas Internet Consulting
701 Brazos, Suite 500
Austin, TX 78701-3243
512-320-9031
Volume-Number: Volume 12, Number 21
From fletcher Mon Aug 24 19:42:30 1987
Posted-Date: 24 Aug 87 23:29:40 GMT
Received-Date: Mon, 24 Aug 87 19:42:30 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA15827; Mon, 24 Aug 87 19:42:30 CDT
From: John Quarterman <jsq@usenix.uucp>
Newsgroups: comp.std.unix
Subject: Pipe Write Problems
Message-Id: <8833@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: jsq@usenix.uucp (John Quarterman)
Date: 24 Aug 87 23:29:40 GMT
Apparently-To: std-unix-archive
From: jsq@usenix.uucp (John Quarterman)
Pipe Write Problems Page 1 of 11 IEEE 1003.1 N.116
John S. Quarterman
Institutional Representative
From USENIX to IEEE P1003
{uunet,ucbvax,seismo}!usenix!jsq
Texas Internet Consulting
701 Brazos, Suite 500
Austin, Texas 78701-3243
+1-512-320-9031
jsq@longway.tic.com
24 August 1987
Attention: P1003 Working Group
Secretary, IEEE Standards Board
345 East 47th Street
New York, NY 10017
Cc: 1003.1 Technical Reviewers:
Maggie Lee, 2 Jeff Smits, 6 Hal Jespersen, Rationale
+1-408-746-7216 +1-201-522-6263 +1-415-420-6400
ihnp4!amdahl!maggie ihnp4!attunix!smits ucbvax!unisoft!hlj
There are several problems in IEEE Std 1003.1, Draft 11
regarding writes to a pipe or FIFO. These problems are
sufficient to produce a no ballot from USENIX. This
objection includes discussion of the problems, their
sources, and suggested solutions, including both standard
and rationale text.
1. Problems
1.1 Ambiguous O_NONBLOCK wording in Draft 11, 6.4.2.2.
Understanding the case of the triple condition
+ O_NONBLOCK is set,
+ and {PIPE_BUF} < nbyte <= {PIPE_MAX},
+ and 0 < immediately writable < nbyte,
requires a close reading of Draft 11, 6.4.2.2, page 125,
lines 224-227:
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 2 of 11 IEEE 1003.1 N.116
If the O_NONBLOCK flag is set, write() shall not block
the process. If nbyte > {PIPE_BUF}, and some data can
be written without blocking the process, write() shall
write what it can and return the number of bytes
written. Otherwise, it shall return -1 and errno shall
be set to [EAGAIN].
It is not immediately obvious what ``Otherwise'' refers to
(which clause of the condition?). But in the context of the
paragraph at lines 217-221 it must refer to the case when
{PIPE_BUF} < nbyte <= {PIPE_MAX} and no data can be written
without blocking the process.
1.2 Nonblocking partial pipe writes are an option in
Draft 11.
According to David Willcox, who was in many of the atomic
pipe write small groups, the word ``can'' in both uses in
the preceding quote is meant to refer to what the
implementation permits. In other words, the case where
``some data can be written'' may refer to there being some
space free in the pipe, or the case may be null, meaning
that [EAGAIN] will always be returned when {PIPE_BUF} <
nbyte <= {PIPE_MAX}, regardless of whether there is free
space in the pipe or not. Which is to say that the standard
permits the implementation to perform partial writes, but
does not require it to do so.
Partial writes are not implementation-defined (according to
the definition in 2.1), because the standard completely
describes their behavior (or attempts to). So partial
writes are an interface implementation option in Draft 11,
even though they are not properly specified as such by the
use of the word ``may'' or listing in 2.2.1.2.
1.3 Incorrect error code?
If partial writes are not implemented, the error [EAGAIN] is
not appropriate, because the write will never succeed, no
matter how many times it is retried. Better would be
[EINVAL], which matches the other cases where retrying will
not help. However, this argument assumes that {PIPE_BUF} is
not only the maximum atomic size, but also the maximum
amount writable on one operation: this may not be so; see
below.
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 3 of 11 IEEE 1003.1 N.116
1.4 {PIPE_MAX} with O_NONBLOCK clear.
Should {PIPE_MAX} apply when O_NONBLOCK is not set? All of
Version 7, System V Release 3, 4.2BSD, and 4.3BSD permit
arbitrarily large values of nbyte when O_NDELAY is not set.
While it is possible to imagine a system where such a limit
would be required by the implementation, there seem to be
none at the moment, so there are probably no applications
that depend on it. The enforcement of such a limit would
make pipes basically different from other things that
write() can be applied to, requiring extra code in
applications. Thus there is no obvious advantage in
portability for applications. So {PIPE_MAX} should not be
applied when O_NONBLOCK is clear.
2. Sources of the problems.
There are three basic sources of confusion about the
behavior of pipes and FIFOs (especially when the non-
blocking flag is set):
1. It is not clear what the various existing systems do.
2. It is clear that they do many things differently.
3. It is not clear what behavior is important to
applications, and thus worth standardizing.
2.1 Existing systems.
Some of the following descriptions may not be totally
accurate, but they should serve to illustrate the point of
diversity.
+ Version 7 introduced atomicity of writes to pipes. The
manual page write(2) guarantees that write requests of
4096 bytes or less will not be interleaved with writes
from any other process. The purpose of this feature
was to allow multiple processes to write to the same
pipe while permitting a single reader to parse their
data.
4096 also happens to be the size of a pipe, and is
fixed at compile time (it is not larger because that
would have made pipes large files, that is, they would
have had indirect blocks).
Any amount (that will fit in an int) of data may be
requested on a single call to write().
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 4 of 11 IEEE 1003.1 N.116
Version 7 does not have a non-blocking flag.
+ The SVID requires atomicity of writes to pipes when the
request is of {PIPE_BUF} bytes or less. This feature
may have been introduced from the /usr/group Standard,
which had it.
There is no maximum write request, regardless of
whether O_NDELAY is set.
With O_NDELAY set, write requests of less than
{PIPE_BUF} bytes either succeed or return zero. Write
requests of more than that may also succeed partially,
returning the amount written.
+ 4.2BSD appears to guarantee atomicity of pipe write
requests up to 1024 bytes. It will return an error for
requests for more than 4096 bytes when the O_NDELAY
flag is set. Partial writes are not done. With the
flag clear, any size write request will succeed
eventually.
+ 4.3BSD does not guarantee atomicity of any size pipe
write (greater than one byte). The maximum amount that
can be requested will vary dynamically, as will the
maximum amount that can be written on a single
operation. With the O_NDELAY flag set, any write of
more than one byte may be partial. UCB CSRG is
probably amenable to changing this behavior.
+ Version 8 does not necessarily measure the maximum
amount of data that can be written to a pipe on a given
operation in bytes, i.e., it may depend on the number
of outstanding write requests.
There is no nonblocking flag in Version 8 or Version 9.
2.2 Useful behavior.
It is more useful to specify how an application should
interpret a return value than it is to specify precisely
when the implementation shall return it. I believe this
observation may be the rope for climbing out of the chronic
pipe write morasse.
[EAGAIN] should mean that retrying later with the same
size request may succeed. The Rationale should
recommend actions the application should take in
such a case. Because some systems dynamically
vary their pipe size, what would have succeeded
this time on an empty pipe may not succeed next
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 5 of 11 IEEE 1003.1 N.116
time. Of course, if the request was for
{PIPE_BUF} or less bytes, retries shall
eventually succeed (unless no reader reads
enough from the pipe). But it is not useful for
the standard to attempt to specify for exactly
what larger requests [EAGAIN] will be returned,
or the probability of success on later retries.
After all, if the reader does not read, no
retries will succeed.
[EINVAL] should mean that retrying later with the same
size request shall never succeed. But the
standard should not require the implementation
to always return this error at a fixed limit.
There is no reason for the standard to try to specify what
happens in every corner case produced by the intersections
of all the known implementations. The standard should
specify behavior that promotes portability of applications
and that is implementable relatively readily on existing
systems. In addition, the behavior of writes to pipes or
FIFOs should be made as little different from that of writes
to other file descriptors as possible. The main reason for
making it different at all is that POSIX does not currently
include any more sophisticated interprocess communication
facility: for example, given a reliable sequenced datagram
service, there would be no need to require pipes to be
atomic.
1. Atomic writes are useful. The standard should specify
that write requests of {PIPE_BUF} or less bytes shall
be atomic, regardless of whether O_NONBLOCK is set.
2. Write requests of more than {PIPE_BUF} bytes with
O_NONBLOCK set are useful. A real time data
acquisition process might want to write large amounts
of data through a pipe to a single processing process,
while never blocking.
3. Partial writes are useful, but not useful enough for
the standard to require the implementation to include
them. The standard should require portable
applications to expect them, however: since the
application should expect them for other kinds of
writes, anyway. In other words, partial writes should
not be a major option, instead merely an
implementation-defined detail. Exactly when they
occur is not important enough to specify (especially
considering that it is not specified for other kinds
of writes), except that they are prohibited when nbyte
<= {PIPE_BUF} because of the guarantee of atomicity.
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 6 of 11 IEEE 1003.1 N.116
There is no strong reason for an application to be
able to discover at compile or run time whether
partial writes are implemented: every application
should assume that they may be implemented.
The usefulness of {PIPE_MAX} is slightly dubious, and it
might be better to eliminate it, instead specifying that
[EINVAL] may be returned whenever O_NONBLOCK is set and
nbyte > {PIPE_BUF}. But let us assume that it is useful.
1. A maximum amount that can be requested without ever
producing [EINVAL] is worthwhile. {PIPE_MAX} could be
used for this. But it should not apply if O_NONBLOCK
is not set.
2. {PIPE_MAX} >= {PIPE_BUF}. Allowing {PIPE_MAX} <
{PIPE_BUF} would permit a guaranteed atomic write to
return [EINVAL], which is a contradiction.
3. The standard should explicitly permit an
implementation to set {PIPE_MAX} = {PIPE_BUF}, simply
because there is no reason to prohibit it. This would
not rule out partial writes, but would mean that
applications running on such an implementation should
never depend on successful writes with nbyte >
{PIPE_BUF}.
4. The standard should permit an implementation to set
{PIPE_MAX} = {INT_MAX}, meaning that [EINVAL] will
never be returned. That is effectively what some
implementations do, and there is no reason not to if
partial writes are implemented.
5. An implementation could even set all three limits
equal: {PIPE_BUF} = {PIPE_MAX} = {INT_MAX}, meaning
that [EINVAL] will never be returned, there are no
partial writes, and all writes are atomic.
Finally, this is an interface standard: it should not try to
specify implementation details, such as the internal
buffering arrangements of the pipe. Such phrases as ``it
shall write as much as it can'' are inappropriate.
3. Rewording.
Here is rewording to account for the implications of the
above arguments.
The text and tables below include specifications and
rationale for {PIPE_MAX}. But, if the Working Group decides
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 7 of 11 IEEE 1003.1 N.116
to drop {PIPE_MAX}, it can be excised with no ill effects.
References to it should then also be removed from Draft 11
2.9.2, page 42, lines 808-810, and 5.7.1.2, page 117, line
971.
3.1 Standard.
Move the definition of {PIPE_MAX} down into the text that
specifies what happens when O_NONBLOCK is set. That is,
first remove Draft 11 6.4.2.2, page 125, lines 215-216:
Write requests for greater than {PIPE_MAX} bytes shall
result in a return of value of -1 and set errno to
[EINVAL].
Then replace the wording (quoted in 1.1 above) of Draft 11,
6.4.2.2, page 125, lines 224-227 with this new wording:
If the O_NONBLOCK flag is set, write requests shall be
handled differently in the following ways: The write()
function shall not block the process. Write requests
for {PIPE_BUF} or less bytes shall either succeed
completely and return nbyte, or return -1 and set errno
to [EAGAIN] to indicate that retrying the write() later
with the same arguments may succeed. Write requests
for more than {PIPE_BUF} bytes may in addition write
some amount of data less than nbyte and return the
amount written. Write requests for more than
{PIPE_MAX} bytes may in addition return -1 and set
errno to [EINVAL] to indicate that retrying the write()
later with the same arguments shall never succeed.
{PIPE_MAX} shall be greater than or equal to {PIPE_BUF}
and less than or equal to {INT_MAX}.
The beginning of the following paragraph, 6.4.2.2, page 125,
lines 228-229, is misleading and should be changed from
When attempting to write to a file descriptor...
to
When attempting to write to a file descriptor (other
than one for a pipe or FIFO)...
The meaning of [EINVAL] when set by write() as specified in
6.4.2.4, page 126, lines 260-261, should be changed from
[EINVAL] An attempt was made to write more than
{PIPE_MAX} bytes to a pipe or FIFO special file.
to
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 8 of 11 IEEE 1003.1 N.116
[EINVAL] An attempt was made to write to a pipe or FIFO
special file with a value of nbyte greater than
{PIPE_MAX} and also large enough that the
operation shall never succeed if retried.
3.2 Rationale.
In the Rationale, remove the editorial note from B.6.4.2,
Page 240, line 2104, and replace B.6.4.2, Page 240, line
2105 (``Write to a Pipe'') with:
[begin replacement]
An attempt to write to a pipe or FIFO has several major
characteristics:
Atomic/non-atomic
A write is atomic if the whole amount written in one
operation is not interleaved with data from any other
process. This is useful when there are multiple
writers sending data to a single reader. Applications
need to know how large a write request can be expected
to be performed atomically. We call this maximum
{PIPE_BUF}. The standard does not say whether write
requests for more than {PIPE_BUF} bytes will be atomic,
but requires that writes of {PIPE_BUF} or less bytes
shall be atomic.
Blocking/immediate
Blocking is only possible with O_NONBLOCK clear. If
there is enough space for all the data requested to be
written immediately, the implementation should do so.
Otherwise, the process may block, that is, pause until
enough space is available for writing. The effective
size of a pipe or FIFO (the maximum amount that can be
written in one operation without blocking) may vary
dynamically, depending on the implementation, so it is
not possible to specify a fixed value for it.
Complete/partial/deferred
A write request,
int fildes, nbyte, ret;
char *buf;
ret = write(fildes, buf, nbyte);
may return
complete: ret = nbyte
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 9 of 11 IEEE 1003.1 N.116
partial: ret < nbyte
This shall never happen if nbyte <=
{PIPE_BUF}. If it does happen (with nbyte
> {PIPE_BUF}), the standard does not
guarantee atomicity, even if ret <=
{PIPE_BUF}, because atomicity is guaranteed
according to the amount requested, not the
amount written.
deferred: ret = -1, errno = [EAGAIN]
This error indicates that a later request
may succeed. It does not indicate that it
shall succeed, even if nbyte <= {PIPE_BUF},
because if no process reads from the pipe
or FIFO, the write will never succeed. An
application could usefully count the number
of times [EAGAIN] is caused by a particular
value of nbyte > {PIPE_BUF} and perhaps do
later writes with a smaller value, on the
assumption that the effective size of the
pipe may have decreased.
Partial and deferred writes are only possible with
O_NONBLOCK set.
Requestable/invalid
If a write request shall never succeed with the value
given for nbyte, the request is invalid, and write()
shall return -1 with errno set to [EINVAL]. This is
only permitted to happen when nbyte > {PIPE_MAX} and
O_NONBLOCK is set, and it is never required to happen.
{PIPE_MAX} is not necessarily a minimum on the
effective size of a pipe or FIFO; if it says anything
about that size, it is that it sometimes varies above
{PIPE_MAX}. Because {PIPE_MAX} specifies the maximum
size write request that shall never cause [EINVAL], it
must be greater than or equal to the maximum atomic
write size, {PIPE_BUF}. {PIPE_BUF} and {PIPE_MAX} may
be equal, which means that [EINVAL] may be produced by
any write of greater than {PIPE_BUF} bytes. {PIPE_MAX}
may be equal to {INT_MAX}, meaning that [EINVAL] shall
never be returned (unless nbyte > {INT_MAX}, when the
result is implementation-defined). All three limits
may be equal, meaning that [EINVAL] shall never be
returned, no partial writes are done, and all completed
writes are atomic. Applications should be prepared for
all these cases.
The relations of these properties are best shown in tables.
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 10 of 11 IEEE 1003.1 N.116
________________________________________________
| Write to a Pipe or FIFO with O_NONBLOCK clear.|
|_____________|_________________________________|
| immediately | |
| writable: | none some nbyte |
|_____________|_________________________________|
| | atomic atomic atomic |
| nbyte <= | blocking blocking immediate|
| {PIPE_BUF} | nbyte nbyte nbyte |
|_____________|_________________________________|
| | atomic? atomic? atomic? |
| nbyte > | blocking blocking immediate|
| {PIPE_BUF} | nbyte nbyte nbyte |
|_____________|_________________________________|
If the O_NONBLOCK flag is clear, a write request shall block
if the amount writable immediately is less than that
requested. If the flag is set (by fcntl()), a write request
shall never block.
__________________________________________________________
| Write to a Pipe or FIFO with O_NONBLOCK set. |
|____________|____________________________________________|
| immediately| |
| writable: | none some nbyte |
|____________|____________________________________________|
| nbyte <= | -1, -1, atomic |
| {PIPE_BUF} | [EAGAIN] [EAGAIN] nbyte |
|____________|____________________________________________|
| | atomic? atomic? |
| | < nbyte <=nbyte |
| nbyte > | -1, or -1, or -1, |
| {PIPE_BUF} | [EAGAIN] [EAGAIN] [EAGAIN] |
|____________|____________________________________________|
| | atomic? atomic? |
| | < nbyte <=nbyte |
| nbyte > | -1, or -1, or -1, |
| {PIPE_MAX} | ([EAGAIN] ([EAGAIN] ([EAGAIN] |
| | or [EINVAL]) or [EINVAL]) or [EINVAL])|
|____________|____________________________________________|
There is no way provided for an application to determine
whether the implementation will ever perform partial writes
to a pipe or FIFO. Every application should be prepared to
handle partial writes when O_NONBLOCK is set and the
requested amount is greater than {PIPE_BUF}, just as every
application should be prepared to handle partial writes on
other kinds of file descriptors.
Where the standard requires -1 returned and errno set to
[EAGAIN], most historical implementations return 0 (with the
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
Pipe Write Problems Page 11 of 11 IEEE 1003.1 N.116
O_NDELAY flag set: that flag is the historical predecessor
of O_NONBLOCK, but is not itself in the standard). The
error indications in the standard were chosen so that an
application can distinguish these cases from end of file.
While write() cannot receive an indication of end of file,
read() can, and the Working Group chose to make the two
functions have similar return values. Also, some existing
systems (e.g., Version 8) permit a write of zero bytes to
mean that the reader should get an end of file indication:
for those systems, a return value of zero from write
indicates a successful write of an end of file indication.
[end replacement]
$Revision: 3.1 $ DRAFT $Date: 87/08/24 10:54:56 $
CONTENTS
1. Problems............................................. 1
1.1 Ambiguous O_NONBLOCK wording in Draft 11,
6.4.2.2......................................... 1
1.2 Nonblocking partial pipe writes are an option
in Draft 11..................................... 2
1.3 Incorrect error code?........................... 2
1.4 {PIPE_MAX} with O_NONBLOCK clear................ 3
2. Sources of the problems.............................. 3
2.1 Existing systems................................ 3
2.2 Useful behavior................................. 4
3. Rewording............................................ 6
3.1 Standard........................................ 7
3.2 Rationale....................................... 8
- i -
Volume-Number: Volume 12, Number 22
From fletcher Mon Sep 14 18:06:19 1987
Posted-Date: 14 Sep 87 17:47:24 GMT
Received-Date: Mon, 14 Sep 87 18:06:19 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA05563; Mon, 14 Sep 87 18:06:19 CDT
From: Peter Salus <peter@usenix.uucp>
Newsgroups: comp.std.unix
Subject: POSIX Workshop
Keywords: POSIX, standards, P1003
Message-Id: <9012@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: peter@usenix.uucp (Peter Salus)
Date: 14 Sep 87 17:47:24 GMT
Apparently-To: std-unix-archive
From: usenix!peter@ucbvax.berkeley.edu (Peter Salus)
POSIX Portability Workshop
Berkeley Marina Marriott
October 22-23, 1987
This USENIX workshop will bring together system and application
implementors faced with the problems, "challenges," and other
considerations that arise from attempting to make their products
compliant with IEEE Standard 1003.1. The first day of the workshop
will consist of presentations of brief position papers describing
experiences, dilemmas, and solutions. On the second day it is
planned to form smaller focus groups to brainstorm additional
solutions, dig deeper into specific areas, and attempt to forge
common approaches to some of the dilemmas.
Program chair:
Jim McGinness
Digital Equipment Corporation
(603) 884-5703
decvax!jmcg
jmcg@decvax.DEC.COM
For registration or hotel information, contact:
Judith F. DesHarnais
USENIX Conference Coordinator
PO Box 385
Sunset Beach, CA 90742
(213) 592-3243
usenix!judy
WORKSHOP EVENT SCHEDULE
Wednesday evening, October 21
No host reception, 7:30pm - 10:00pm
Thursday, October 22
Workshop. 9:00am - 5:00pm
Friday, October 23
Workshop, 9:00am - 5:00pm
WORKSHOP REGISTRATION INFORMATION
You MUST register in advance to attend this limited enrollment
workshop. Register early as space is available on a first-come,
first-served basis.
REGISTRATION FEE.............$200.00
REGISTRATION DEADLINE........October 12, 1987
REFUND CANCELLATION POLICY
If you must CANCEL, all refund requests must be in writing and
postmarked no later than October 14, 1987. Direct your letter to
the USENIX Conference Office.
HOTEL INFORMATION
The workshop will be held at:
Berkeley Marina Marriott
200 Marina Blvd.
Berkeley, CA 94710
Telephone: (415) 548-7920
Toll Free: 1-800-228-9290
TO MAKE YOUR RESERVATION
Call the Hotel directly and ask for the Reservation Desk. Tell
reservations that you are a USENIX Conference attendee to take
advantage of our group rate. You may guarantee your late arrival
with a major credit card.
!!!!!!IMPORTANT: Hotel deadline for making
your reservation is October 7, 1987.
Reservation requests
received after the deadline
will be handled on a space and RATE
available basis.
RATE: $85.00/night - single or double occupancy (Plus 11% hotel
tax)
AIRPORT TO HOTEL TRANSPORTATION
The Berkeley Marina Marriott is about 15 minutes from the Oakland
International Airport. The Marriott has free shuttle service
available from the Oakland airport from 6:45am - 9:45pm. After
arriving at the Oakland airport, call the Berkeley Marina Mar-
riott from the baggage claim area hotel information phones to
make arrangements. Bay Area Shuttle Service is also available
from the Oakland airport for about $6 and from the San Francisco
Airport for about $12 one way. If you would like to go to San
Francisco during your stay at the Marriott, please contact the
Bellman who will be happy to shuttle you to the Bart Station.
Volume-Number: Volume 12, Number 23
From fletcher Wed Sep 16 12:58:00 1987
Posted-Date: 16 Sep 87 17:57:48 GMT
Received-Date: Wed, 16 Sep 87 12:58:00 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA16935; Wed, 16 Sep 87 12:58:00 CDT
From: Andy Glew <aglew%ccvaxa.UUCP@sally.utexas.edu>
Newsgroups: comp.std.unix
Subject: Unusual Filesystems and POSIX
Message-Id: <9027@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: aglew@ccvaxa.UUCP (Andy Glew)
Date: 16 Sep 87 17:57:48 GMT
Apparently-To: std-unix-archive
From: aglew@ccvaxa.UUCP (Andy Glew)
I am wondering what aspects of the POSIX standard impose
constraints upon unusual implementations of the filesystem.
Eg. instead of UNIX's directories containing lists of names
and inodes, what about a filesystem that was basically just
a big hash table of the entire path - directories simply being
entries required to be present before subsidiary files are
created, not actually containing the names of subsidiary files.
Is there anything in POSIX that would prevent this?
Eg2. is the extra level of indirection filename->inode required,
or is it possible simply to refuse links? And so on.
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa
I always felt that disclaimers were silly and affected, but there are people
who let themselves be affected by silly things, so: my opinions are my own,
and not the opinions of my employer, or any other organisation with which I am
affiliated. I indicate my employer only so that other people may account for
any possible bias I may have towards my employer's products or systems.
Volume-Number: Volume 12, Number 24
From fletcher Fri Sep 18 20:30:25 1987
Posted-Date: 18 Sep 87 19:14:32 GMT
Received-Date: Fri, 18 Sep 87 20:30:25 CDT
Received: by sally.utexas.edu (5.54/5.51)
id AA23238; Fri, 18 Sep 87 20:30:25 CDT
From: Bob Bagwill <bagwill@decuac.uucp>
Newsgroups: comp.std.unix
Subject: Re: Unusual Filesystems and POSIX
Summary: POSIX doesn't prescribe directories' internal structure.
Message-Id: <9052@ut-sally.UUCP>
References: <9027@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: bagwill@decuac.uucp (Bob Bagwill)
Organization: DEC SWS, Landover, MD
Date: 18 Sep 87 19:14:32 GMT
Apparently-To: std-unix-archive
From: mimsy!cvl!decuac!bagwill@rutgers.edu (Bob Bagwill)
Draft 11: "The internal format of directories is implementation
defined...." There must be a <dirent.h>, and a typedef DIR, and the
following routines: opendir(), readdir(), rewinddir(), closedir()
and a directory must be a file. How it is implemented is left up to
the implementor.
Volume-Number: Volume 12, Number 25
From jsq Thu Nov 5 21:01:02 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA21734; Thu, 5 Nov 87 21:01:02 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <2843@uunet.UU.NET>
Reply-To: std-unix@uunet.UU.NET
Date: 6 Nov 87 01:58:11 GMT
Apparently-To: std-unix-archive
This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.
Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and utilities),
1003.3 (testing and verification), 1003.4 (real time).
NBS FIPS.
/usr/group working groups on distributed file system, network interface,
graphics/windows, database, internationalization,
performance measurements, realtime, security, and super computing.
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals
UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.
The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee. They published the 1003.1 "POSIX" Trial Use
Standard in April 1986. According to its Foreword:
The purpose of this document is to define a standard
operating system interface and environment based on the
UNIX Operating System documentation to support application
portability at the source level. This is intended for
systems implementors and applications software developers.
Published copies are available at $19.95, with bulk purchasing discounts
available. Call the IEEE Computer Society in Los Angeles
714-821-8380
and ask for Book #967. Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:
IEEE Computer Society
P.O. Box 80452
Worldway Postal Center
Los Angeles, Ca. 90080
Include a check for $19.95 + $4 for shipping and handling. For UPS
shipping, add another $4. Or contact:
IEEE Service Center
445 Hoes Ln.
Piscataway, NJ 08854
and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.
The Trial Use Standard will be available for comments for a period
such as a year. The current target for a Full Use Standard is Spring 1988.
The current draft, Draft 12, is being balloted on starting 15 November 1987.
It's too late to join the balloting group, but written objections or comments
are still solicited during the thirty days following that date from everyone
and will be fully considered. The main difference is that only ballots from
the formal balloting group will count toward the numeric goals for returning
ballots and yes yotes. The appropriate address is:
Computer Society Secretariat
IEEE Standards Office
345 East 47th St.
New York, NY 10017
The possible categories for voting are: yes, perhaps with comments;
no, with objections, and perhaps with comments; and yes because of
lack of time or expertise (this last one makes no sense unless you
are in the official balloting quorum). Text of comments and objections
should organized by section of Draft 12, with each major section
at the beginning of a new page. Each remark should be marked as to
whether it is an objection or a non-binding comment, and numbered
within those categories.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena. IEEE
1003.1 Draft 12 is also a ``Draft Proposed International Standard (ISO DP).''
The convenor is Jim Isaak: see below for his address.
The National Bureau of Standards is producing a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1. It will probably
be available before the Full Use Standard, and may reflect Draft 12,
rather than the final 1003.1 standard. For information, contact:
Roger Martin
National Bureau of Standards
Building 225
Room B266
Gaithersburg, MD 20899
(301)975-3295
Machine readable copies of the IEEE 1003.1 Trial Use Standard are not
and will not be available. The same applies to copies of later drafts.
There is a paper mailing list by which interested parties may get
copies of drafts of the standard. To get on it, or to submit comments
directly to the committee, mail to:
James Isaak
Chairperson, IEEE/CS P1003
Digital Equipment
ZK03-3/Y25
110 Spit Brook Rd.
Nashua, NH 03062-2698
Tel.: (603)881-0480
Fax.: (603)881-0120
decvax!isaak
Sufficiently interested parties may join the working group.
The term POSIX also applies to the other P1003 subcommittees:
group subject co-chairs
1003.2 shell and utilities Hal Jespersen (UniSoft), Don Cragun (Sun)
1003.3 verification Roger Martin (NBS), Carol Raye (AT&T)
1003.4 real time Bill Corwin (Intel)
Inquiries regarding 1003.2, 1003.3, and 1003.4 should go to the same address
as for 1003.1.
The next scheduled meetings of the P1003 working groups are,
in 1987 and 1988:
Dec. 7-11 San Diego, CA
P1003.1 group will meet evenings on 7 and 8 and all day on the 11th.
P1003.2 group will meet 7-10 December.
April 1988 Washington, DC
Here are some details from Hal Jespersen regarding P1003.2:
The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard. It will
consist of
a shell command language (currently planned to be based on the
Bourne Shell),
groups of utility programs, or commands,
programmatic interfaces to the shell (system(), popen()) and
related facilities (regular expressions, file name expansion,
etc.)
defined environments (variables, file hierarchies, etc) that
applications may rely upon
utilities for installing application programs onto conforming
systems
which will allow application programs to be developed out of existing
pieces, in the UNIX tradition. The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.
There has been some controversy in the Working Group about clarifying
the scope of the 1003.2 standard in regard to its relationship with
1003.1. The Working Group is attempting to produce a standard that
will assume the structure and philosophy of a POSIX system is
available, but it will not require a fully conforming implementation as
a base. For example, it should be feasible to eventually produce a
1003.2 interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and utilities
didn't need them). However, the proposed standard will *not* be
unnecessarily watered down simply to allow non-POSIX systems to conform.
The group is currently seeking proposals for groupings of commands that
may be offered by implementors. As groups are identified, command
descriptions will be solicited. There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.
There are three Institutional Representatives to P1003: John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Mike Lambert from X/OPEN.
As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee. One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
An article related to this one appeared in the September/October 1986
;login: (The USENIX Association Newsletter). I'm also currently on the
USENIX Board of Directors. Comments, suggestions, etc., may be sent to
John S. Quarterman
Texas Internet Consulting
701 Brazos, Suite 500
Austin TX 78701-3243
+1-512-320-9031
uunet!usenix!jsq
jsq@longway.tic.com
For comp.std.unix:
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
The September/October 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in September 1987.
If you are interested in starting another working group, contact
Heinz Lycklama:
Heinz Lycklama
Interactive Systems Corp.
2401 Colorado Ave., 3rd Floor
Santa Monica, CA 90404
(213)453-8649
decvax!cca!ima!heinz
Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above, and updated by later information
from Heinz Lycklama.
/usr/group Working Group on Distributed File System:
Art Sabsevitz Frederick Glover
AT&T Information Systems MK02-1/H10
190 River Road Digital Equipment Corporation
Summit, NJ 07933 Continental Boulevard
201-522-6248 Merrimack, NH 03054-0430
attunix!bump 603-884-5111
decvax!fglover
/usr/group Working Group on Network Interface:
Steve Albert
AT&T Information Systems
190 River Road, Rm. A-114
Summit, NJ 07901
(201)522-6104
attunix!ssa
/usr/group Working Group on Internationalization:
John Wu Laurie Goudie
Charles River Data Systems Santa Cruz Operation
983 Concord St., 400 Encinal
Framingham, MA 01701 Santa Cruz, CA 95060
617-626-1000 408-458-1422
/usr/group Working Group on Graphics/Windows:
Tom Greene
Apollo Computer, Inc.
330 Billerica Road
Chelmsford, MA 01824
(617)256-6600, ext. 7581
/usr/group Working Group on Realtime:
Bill Corwin
Intel Corp.
5200 Elam Young Pkwy
Hillsboro, OR 97123
(503)681-2248
/usr/group Working Group on Database:
Val Skalabrin
Unify Corp.
1111 Howe Ave.
Sacramento, CA 95825
(916)920-9092
/usr/group Working Group on Performance Measurements:
Ram Chelluri Dave Hinnant
AT&T Computer Systems SCI Systems, Inc.
Room E15B Ste 325, Pamlico Bldg
4513 Western Ave. Research Triangle Pk, NC 27709
Lisle, IL 60532 (919)549-8334
(312)810-6223
/usr/group Working Group on Security:
Steve Sutton Ms. Jeanne Baccash
Consultant, Addamax AT&T UNIX Systems Engineering
1107 S. Orchard 190 River Road
Urbana, IL 61801 Summit, NJ 07901
217-344-0996 201-522-6028
attunix!jeanne
/usr/group Working Group on Super Computing:
Karen Sheaffer Robin O'Neill
Sandia National Laboratory Lawrence Livermore Laboratory
P.O. Box 969 P.O. Box 5509, L560
Livermore, CA 94550 Livermore, CA 94550
415-422-3431 415-422-0973
oneill#r%mfe@lll-mfe.arpa Co-chair
The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system. The chair solicits
help and participation:
Georges Grinstein
wanginst!ulowell!grinstein
The Abstract of the 1003.1 Trial Use Standard adds:
This interface is a complement to the C Programming Language
in the C Information Bulletin prepared by Technical Committee X3J11
of the Accredited Standards Committee X3, Information Processing
Systems, further specifying an environment for portable application
software.
X3J11 is sometimes known as the C Standards Committee. Their liaison to
P1003 is
Don Kretsch
AT&T
190 River Road
Summit, NJ 07901
A contact for information regarding publications and working groups is
Thomas Plum
Vice Chair, X3J11 Committee
Plum Hall Inc.
1 Spruce Avenue
Cardiff, New Jersey 08232
The current document may be ordered from
Global Press
2625 Hickory St.
P.O. Box 2504
Santa Anna, CA 92707-3783
U.S.A.
800-854-7179
+1-714-540-9870 (from outside the U.S., ask for extension 245.)
TELEX 692 373
Ask for the X3.159 draft standard. The price is $65.
The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11. It may be ordered for $15.00 from:
/usr/group Standards Committee
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
Tel: (408)986-8840
Fax: (408)986-1645
/usr/group also publishes an eight page document, ``Your Guide to POSIX,''
explaining what IEEE 1003 is, and a nineteen page document, ``POSIX Explored,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations. Contact /usr/group at the above address
for details.
The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.
AT&T Customer Information Center
Attn: Customer Service Representative
P.O. Box 19901
Indianapolis, IN 46219
U.S.A.
800-432-6600 (Inside U.S.A.)
800-255-1242 (Inside Canada)
317-352-8557 (Outside U.S.A. and Canada)
System V Interface Definition, Issue 2
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-011 Volume I Base System
Kernel Extension
320-012 Volume II Basic Utilities Extension
Advanced Utilities Extension
Software Development Extension
Administered System Extension
Terminal Volume Interface Extension
320-013 Volume III Base System Addendum
Terminal Interface Extension
Network Services Extension
307-131 I, II, III (all three volumes)
The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders: mail orders
should include a check or money order, payable to AT&T.
The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.
The X/OPEN Group is "Ten of the world's major information system
suppliers" (at time of publication, Bull, DEC, Ericsson, Hewlett-Packard,
ICL, NIXDORF, Olivetti, Philips, Siemens and Unisys and subsequently
augmented by AT&T) who have produced a document intended to promote
the writing of portable applications. They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.
The book is published by
Elsevier Science Publishers B.V.
Book Order Department
P.O. Box 1991
1000 BZ Amsterdam
The Netherlands
and distributed in the U.S.A. and Canada by:
Elsevier Science Publishing Company, Inc.
52 Vanderbilt Avenue
New York, NY 10017
U.S.A.
There are currently five volumes:
1) System V Specification Commands and Utilities
2) System V Specification System Calls and Libraries
3) System V Specification Supplementary Definitions
4) Programming Languages
5) Data Management
They take a large number of credit cards and other forms of payment.
Comments, suggestions, error reports, etc., for Issue 2 of the Green Book
may be mailed directly to:
xpg2@xopen.co.uk
uunet!mcvax!inset!xopen!xpg2
Information about X/OPEN can be requested from:
Mike Lambert
Technical Director
X/OPEN Ltd
c/o ICL BRA01
Lovelace Road
Bracknell
Berkshire
England
+44 344 42 48 42
mgl@xopen.co.uk
uunet!mcvax!inset!xopen!mgl
Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:
Howard Press
c/o USENIX Association
P.O. Box 2299
Berkeley, CA 94710
415-528-8649
{ucbvax,decvax}!usenix!office
4.3BSD User's Manual Set (3 volumes) $25.00
User's Reference Manual
User's Supplementary Documents
Master Index
4.3BSD Programmer's Manual Set (3 volumes) $25.00
Programmer's Reference Maual
Programmer's Supplementary Documents, Volume 1
Programmer's Supplementary Documents, Volume 2
4.3BSD System Manager's Manual (1 volume) $10.00
Unfortunately, there are some license restrictions.
Contact the USENIX office for details.
Volume-Number: Volume 12, Number 26
From jsq Sat Nov 14 16:30:25 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA09246; Sat, 14 Nov 87 16:30:25 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: recent standards activity
Message-Id: <3017@uunet.UU.NET>
Reply-To: std-unix@uunet.UU.NET
Date: 14 Nov 87 21:30:13 GMT
Apparently-To: std-unix-archive
There's not been much activity in this newsgroup lately.
This is slightly surprising, consdiring the amount of activity
about standards lately:
The USENIX POSIX Portability Workshop, resulting in many
comments and objections being fed into the IEEE 1003.1 balloting.
The NBS POSIX Implementation Workshop, producing input to NBS
about their proposed Federal Information Processing Standard (FIPS).
The publication of two documents on POSIX by /usr/group, and the
creation of newsgroups related to the /usr/group Technical Committee.
Balloting on IEEE P1003.1 during the thirty days starting 15 November
(tomorrow).
Concurrent balloting on the same draft of P1003.1 as an ISO draft standard.
Announcements by Sun and AT&T of a joint plan for future development
of UNIX, incorporating both hardware and software.
A decision by the General Services Administration (GSA) regarding
the protest by DEC of an Air Force RFP that specified System V and SVVS.
Quiet progress by P1003.2 and the other P1003 subcommittees.
Some discussion of these things might be interesting.
Volume-Number: Volume 12, Number 27
From jsq Sat Dec 19 18:16:46 1987
Received: by uunet.UU.NET (5.54/1.14)
id AA07944; Sat, 19 Dec 87 18:16:46 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <4284@uunet.UU.NET>
Reply-To: std-unix@uunet.UU.NET
Date: 19 Dec 87 23:16:26 GMT
Apparently-To: std-unix-archive
This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.
Corrections and additions to this article are solicited.
Access information is given in this article for the following:
user groups: USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG, DECUS
journal: Computing Systems
newsletters: ;login:, CommUNIXations, /usr/digest, EUUGN, AUUGN, NUZ
magazines: UNIX REVIEW, UNIX/WORLD, IX Magazine,
UNIX Systems, UNIX Magazine
Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.
UNIX is a Registered Trademark of AT&T.
USENIX is ``The Professional and Technical UNIX(R) Association.''
USENIX Association
P.O. Box 2299
Berkeley, CA 94710
U.S.A.
+1-415-528-8649
{uunet,ucbvax,decvax}!usenix!office
office@usenix.org
USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:
Feb 10-12 1988 Registry Hotel, Dallas, TX, concurrent with Uniforum
Jun 21-24 1988 Hilton Hotel, San Francisco, CA
Feb 1- 3 1989 Town and Country Hotel, San Diego, CA
Jun 13-16 1989 Hyatt Regency, Baltimore, MD
Jun 11-15 1990 Marriott Hotel, Anaheim, CA
They also sponsor workshops, such as
May 12-13 1987 Omni Shoreham Hotel, Washington, DC
Fifth Workshop on Real-Time Software and Operating Systems
IEEE Computer Society and USENIX Association
Proceedings for all conferences and workshops are available at
the door and by mail later.
USENIX publishes ``;login: The USENIX Association Newsletter''
bimonthly. It is sent free of charge to all their members and
includes technical papers. There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.
In 1988, USENIX will start publishing a new refereed quarterly
technical journal, ``Computing Systems: The Journal of the USENIX
Association,'' in cooperation with University of California Press.
They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership. They distribute tapes of contributed software and are
pursuing expanding that activity.
There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.
/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.
/usr/group
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
U.S.A.
tel: +1-408-986-8840
fax: +1-408-986-1645
The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.
Feb 8-11 1988 Infomart, Dallas, TX, concurrent with USENIX
Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
Jan 23-26 1990 Washington Hilton, Washington, DC
Jan 22-25 1991 Infomart, Dallas, TX
Jan 21-24 1992 Moscone Center, San Francisco CA (tentative)
They also sponsor a regional show, UniForum D.C.:
Aug 2-4 1988 Washington Hilton Hotel, Washington, D.C.
Proceedings for all conferences are available at the shows and later
by mail.
/usr/group publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.
/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group. This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.
/usr/group has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Technical Committee
on areas that P1003 has not yet addressed. They have recently produced
an overview of the POSIX standard, ``POSIX Explored,'' and funded production
of a draft of a ``Rationale and Notes'' appendix for that standard.
EUUG is the European UNIX systems Users Group.
EUUG secretariat
Owles Hall
Buntingford
Herts SG9 9PL
England
Telephone +44 763 73039
Telefax +44 763 73260
uunet!mcvax!inset!euug
euug@inset.co.uk
They have a newsletter, EUUGN, and hold two conferences a year.
The next one is in London, England, 11-15 April 1988, followed by
Lisbon, Portugal, in October.
AUUG is the Australian UNIX systems Users Group.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
Phone contact can occasionally be made at +61 3 344 5225
AUUG holds biennial conferences, usually of 2 days each.
The next meeting is in February 1987.
They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.
The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
(in June this year), and publishes a newsletter, ``NUZ.''
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
The Korean UNIX User Group has a software distribution service and a newsletter.
Korean UNIX User Group
ETRI
P.O. Box 8
Daedug Science Town
Chungnam 300-32
Republic of Korea
+82-042-822-4455
The Japan UNIX Society has two meetings a year, and a newsletter.
Japan UNIX Society
#505 Towa-Hanzomon Corp. Bldg.
2-12 Hayabusa-cho
Chiyoda-ku, Tokyo 102
Japan
+81-03-234-2611
There are similar groups in other parts of the world. If such a group
wishes to be included in later versions of this access list, they
should please send me information.
There is a partial list of national organizations in the November/December
1987 CommUNIXations.
Also, DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) which participates
in its meetings, which are held twice a year.
DECUS U.S. Chapter
219 Boston Post Road, BP02
Marlboro, Massachusetts 01752-1850
U.S.A.
+1-617-480-3418
See also the USENET newsgroup comp.org.decus.
The main general circulation (more than 10,000 copies per issue) magazines
about the UNIX system are
UNIX REVIEW UNIX/WORLD
Miller Freeman Publications Co. Tech Valley Publishing
500 Howard Street 444 Castro St.
San Francisco, CA 94105 Mountain View, CA 94041
U.S.A. U.S.A.
+1-415-397-1881 +1-415-940-1500
IX Magazine UNIX Systems
Storyplace Ltd. Eaglehead Publishing Ltd.
137-139 Euston Road Maybury Road
London NW1 2AU Woking, Surrey GU21 5HX
England England
+44-48-6227661
UNIX Magazine
Jouji Ohkubo
c/o ASCII Corp.
jou-o@ascii.junet
+81-3-486-4523
fax: +81-3-486-4520
telex: 242-6875 ASCIIJ
Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters. The following
information about bookstores was taken from the same issue. In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.
Computer Literacy Bookshop UNIX Book Service
2590 No. First St. 35 Bermuda Terrace
San Jose, CA 95131 Cambridge, CB4 3LD
U.S.A. England
+1-408-4350-1118 +44-223-313273
Cucumber Bookshop Jim Joyce's UNIX Book Store
5611 Kraft Ave. 47 Potomac St.
Rockville, MD 20852 San Francisco, CA 94117
U.S.A. U.S.A.
+1-301-881-2722 +1-415-626-7581
Volume-Number: Volume 12, Number 28
From jsq Thu Jan 14 23:47:05 1988
Received: by uunet.UU.NET (5.54/1.14)
id AA24530; Thu, 14 Jan 88 23:47:05 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: POSIX Information
Message-Id: <5142@uunet.UU.NET>
Reply-To: Dominic Dunlop <mcvax!sphinx.co.uk!domo>
Date: 12 Jan 88 10:30:27 GMT
Apparently-To: std-unix-archive
[The following was copied to std-unix in reply to a message of inquiry
that went to another list. -mod]
Thanks for the communication requesting information on how to participate
in POSIX workshops.. Could I ask you instead to direct it to
isaak@decvax.UUCP? Jim Isaaks is the chair of the POSIX working group,
so should be able to tell you exactly what's happening. Alternatively,
ahby@meccts.UUCP (Shane McCarron) is secretary to the group, so he may be
able to help.
In fact, a summary of germane information is posted periodically to the
newsgroup comp.std.unix, which you can see if you're on the news network.
Unfortunately, the last posting has expired, and we don't have a backup here
-- except on paper, and I'm afraid I'm not going to type it in again...
This invaluable information is posted by the moderator of the newsgroup,
John S Quarterman, who can be reached at std-unix@uunet.uu.net. By copy
of this mail, may I shall suggest that, in future, a long expiry date is
put on the postings?
Dominic Dunlop, R&D Director, Sphinx Ltd.
Volume-Number: Volume 12, Number 29
From jsq Thu Jan 14 23:50:20 1988
Received: by uunet.UU.NET (5.54/1.14)
id AA24721; Thu, 14 Jan 88 23:50:20 EST
From: John S. Quarterman <jsq@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX Information
Message-Id: <5143@uunet.UU.NET>
Sender: std-unix@uunet.UU.NET
Reply-To: (John S. Quarterman) (uunet!longway!jsq, jsq@longway.tic.com) <longway!jsq>
Date: 14 Jan 88 16:41:31 GMT
Apparently-To: std-unix-archive
>Thanks for the communication requesting information on how to participate
>in POSIX workshops..
A possible source of confusion is that there were two POSIX-related workshops
last year, but none scheduled for this year, that I know of. The part of
the POSIX committee that writes the standards is called the working group,
and meets four times a year.
>Could I ask you instead to direct it to isaak@decvax.UUCP?
Also reachable as isaak@decvax.dec.com.
> By copy of this mail, may I shall suggest that, in future, a long expiry
> date is put on the postings?
Good idea. I don't want it to be too long, because the information changes.
But I will attempt to guess when I will next have an update ready, and put
an expiration on it for that interval.
The next posting of the access message follows in comp.std.unix.
It includes the schedule for POSIX working group meetings.
Volume-Number: Volume 12, Number 30
From jsq Fri Jan 15 12:20:55 1988
Received: by uunet.UU.NET (5.54/1.14)
id AA03407; Fri, 15 Jan 88 12:20:55 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <5162@uunet.UU.NET>
Reply-To: std-unix@uunet.UU.NET
Date: 15 Jan 88 17:20:39 GMT
Apparently-To: std-unix-archive
This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.
Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
1003.3 (testing and verification), 1003.4 (real time),
1003.5 (ADA binding), 1003.6 (security), 1003.0 (POSIX guide).
NBS FIPS.
/usr/group working groups on distributed file system, network interface,
graphics/windows, database, internationalization,
performance measurements, realtime, security, and super computing.
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals
UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.
The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee. They published the 1003.1 "POSIX" Trial Use
Standard in April 1986. According to its Foreword:
The purpose of this document is to define a standard
operating system interface and environment based on the
UNIX Operating System documentation to support application
portability at the source level. This is intended for
systems implementors and applications software developers.
Published copies are available at $19.95, with bulk purchasing discounts
available. Call the IEEE Computer Society in Los Angeles
714-821-8380
and ask for Book #967. Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:
IEEE Computer Society
P.O. Box 80452
Worldway Postal Center
Los Angeles, Ca. 90080
Include a check for $19.95 + $4 for shipping and handling. For UPS
shipping, add another $4. Or contact:
IEEE Service Center
445 Hoes Ln.
Piscataway, NJ 08854
and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.
The Trial Use Standard will be available for comments for a period
such as a year. The current target for a Full Use Standard is Spring 1988.
Initial balloting is completed, and ballot resolution is in progress:
it's too late to ballot if you haven't already.
IEEE has brought the 1003.1 effort brought into the International
Organization for Standardization (ISO) arena. IEEE 1003.1 Draft 12
is also a ``Draft Proposed International Standard (ISO DP)'' under
SC22 WG15. The convenor is Jim Isaak: see below for his address.
There is a U.S. Technical Advisory Group (TAG) to ISO SC22 WG15:
the chair is Donn Terry of HP.
The National Bureau of Standards is producing a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1. It will probably
be available before the Full Use Standard, and may reflect Draft 12,
rather than the final 1003.1 standard. For information, contact:
Roger Martin
National Bureau of Standards
Building 225
Room B266
Gaithersburg, MD 20899
(301)975-3295
Machine readable copies of the IEEE 1003.1 Trial Use Standard are not
and will not be available. The same applies to copies of later drafts.
There is a paper mailing list by which interested parties may get
copies of drafts of the standard. To get on it, or to submit comments
directly to the committee, mail to:
James Isaak
Chairperson, IEEE/CS P1003
Digital Equipment
ZK03-3/Y25
110 Spit Brook Rd.
Nashua, NH 03062-2698
Tel.: (603)881-0480
Fax.: (603)881-0120
decvax!isaak
Sufficiently interested parties may join the working group.
The term POSIX actually applies to all of the P1003 subcommittees:
group subject co-chairs
1003.0 POSIX Guide
1003.1 Systems Interface Jim Isaak (DEC), Donn Terry (HP)
1003.2 Shell and Tools Interface Hal Jespersen (UniSoft), Don Cragun (Sun)
1003.3 Verification and Testing Roger Martin (NBS), Carol Raye (AT&T)
1003.4 Real Time Bill Corwin (Intel)
1003.5 Ada Binding for POSIX
1003.6 Security
Inquiries regarding any of the subcommittees should go to the same address
as for 1003.1.
The next scheduled meetings of the P1003 working groups are:
1988 March 14-18 Ritz-Carlton Hotel, Washington, DC
1988 June 27-July 1 Colorado Springs, CO
1988 October 10-14 Hawaii
1988 October 17-19+ ISO SC22 Advisory Group & WG15 - Tokyo, Japan
1989 January Ft. Lauderdale, FL
1989 April Minneapolis-St. Paul, MN
1989 June Monterey, CA
1989 October Brussels (or Amsterdam) (Thought: EC host)
1990 January New Orleans, LA
Here are some details from Hal Jespersen regarding P1003.2:
The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard. It will
consist of
a shell command language (currently planned to be based on the
Bourne Shell),
groups of utility programs, or commands,
programmatic interfaces to the shell (system(), popen()) and
related facilities (regular expressions, file name expansion,
etc.)
defined environments (variables, file hierarchies, etc) that
applications may rely upon
utilities for installing application programs onto conforming
systems
which will allow application programs to be developed out of existing
pieces, in the UNIX tradition. The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.
There has been some controversy in the Working Group about clarifying
the scope of the 1003.2 standard in regard to its relationship with
1003.1. The Working Group is attempting to produce a standard that
will assume the structure and philosophy of a POSIX system is
available, but it will not require a fully conforming implementation as
a base. For example, it should be feasible to eventually produce a
1003.2 interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and utilities
didn't need them). However, the proposed standard will *not* be
unnecessarily watered down simply to allow non-POSIX systems to conform.
The group is currently seeking proposals for groupings of commands that
may be offered by implementors. As groups are identified, command
descriptions will be solicited. There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.
There are three Institutional Representatives to P1003: John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Mike Lambert from X/OPEN.
The two from USENIX and /usr/group are also representatives to the U.S.
TAG to ISO SC22 WG15.
As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee. One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
An article related to this one appeared in the September/October 1986
;login: (The USENIX Association Newsletter). I'm also currently on the
USENIX Board of Directors. Comments, suggestions, etc., may be sent to
John S. Quarterman
Texas Internet Consulting
701 Brazos, Suite 500
Austin TX 78701-3243
+1-512-320-9031
uunet!usenix!jsq
jsq@longway.tic.com
For comp.std.unix:
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
The November/December 1987 issue of CommUNIXations (the /usr/group magazine)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in June 1987.
If you are interested in starting another /usr/group working group, contact
Heinz Lycklama:
Heinz Lycklama
Interactive Systems Corp.
2401 Colorado Ave., 3rd Floor
Santa Monica, CA 90404
(213)453-8649
decvax!cca!ima!heinz
Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above.
/usr/group Working Group on Distributed File System:
Art Sabsevitz Frederick Glover
AT&T Information Systems MK02-1/H10
190 River Road Digital Equipment Corporation
Summit, NJ 07933 Continental Boulevard
201-522-6248 Merrimack, NH 03054-0430
attunix!bump 603-884-5111
decvax!fglover
/usr/group Working Group on Network Interface:
Steve Albert
AT&T Information Systems
190 River Road, Rm. A-114
Summit, NJ 07901
(201)522-6104
attunix!ssa
/usr/group Working Group on Internationalization:
John Wu Laurie Goudie
Charles River Data Systems Santa Cruz Operation
983 Concord St., 400 Encinal
Framingham, MA 01701 Santa Cruz, CA 95060
617-626-1000 408-458-1422
/usr/group Working Group on Graphics/Windows:
Tom Greene
Apollo Computer, Inc.
330 Billerica Road
Chelmsford, MA 01824
(617)256-6600, ext. 7581
/usr/group Working Group on Realtime:
Bill Corwin
Intel Corp.
5200 Elam Young Pkwy
Hillsboro, OR 97123
(503)681-2248
/usr/group Working Group on Database:
Val Skalabrin
Unify Corp.
1111 Howe Ave.
Sacramento, CA 95825
(916)920-9092
/usr/group Working Group on Performance Measurements:
Ram Chelluri Dave Hinnant
AT&T Computer Systems SCI Systems, Inc.
Room E15B Ste 325, Pamlico Bldg
4513 Western Ave. Research Triangle Pk, NC 27709
Lisle, IL 60532 (919)549-8334
(312)810-6223
/usr/group Working Group on Security:
Steve Sutton Ms. Jeanne Baccash
Consultant, Addamax AT&T UNIX Systems Engineering
1107 S. Orchard 190 River Road
Urbana, IL 61801 Summit, NJ 07901
217-344-0996 201-522-6028
attunix!jeanne
/usr/group Working Group on Super Computing:
Karen Sheaffer Robin O'Neill
Sandia National Laboratory Lawrence Livermore Laboratory
P.O. Box 969 P.O. Box 5509, L560
Livermore, CA 94550 Livermore, CA 94550
415-422-3431 415-422-0973
oneill#r%mfe@lll-mfe.arpa
The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system. The chair solicits
help and participation:
Georges Grinstein
wanginst!ulowell!grinstein
The Abstract of the 1003.1 Trial Use Standard adds:
This interface is a complement to the C Programming Language
in the C Information Bulletin prepared by Technical Committee X3J11
of the Accredited Standards Committee X3, Information Processing
Systems, further specifying an environment for portable application
software.
X3J11 is sometimes known as the C Standards Committee. Their liaison to
P1003 is
Don Kretsch
AT&T
190 River Road
Summit, NJ 07901
A contact for information regarding publications and working groups is
Thomas Plum
Vice Chair, X3J11 Committee
Plum Hall Inc.
1 Spruce Avenue
Cardiff, New Jersey 08232
The current document may be ordered from
Global Press
2625 Hickory St.
P.O. Box 2504
Santa Anna, CA 92707-3783
U.S.A.
800-854-7179
+1-714-540-9870 (from outside the U.S., ask for extension 245.)
TELEX 692 373
Ask for the X3.159 draft standard. The price is $65.
The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11. It may be ordered for $15.00 from:
/usr/group Standards Committee
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
Tel: (408)986-8840
Fax: (408)986-1645
/usr/group also publishes an eight page document, ``Your Guide to POSIX,''
explaining what IEEE 1003 is, and a nineteen page document, ``POSIX Explored,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations. Contact /usr/group at the above address
for details.
The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.
AT&T Customer Information Center
Attn: Customer Service Representative
P.O. Box 19901
Indianapolis, IN 46219
U.S.A.
800-432-6600 (Inside U.S.A.)
800-255-1242 (Inside Canada)
317-352-8557 (Outside U.S.A. and Canada)
System V Interface Definition, Issue 2
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-011 Volume I Base System
Kernel Extension
320-012 Volume II Basic Utilities Extension
Advanced Utilities Extension
Software Development Extension
Administered System Extension
Terminal Volume Interface Extension
320-013 Volume III Base System Addendum
Terminal Interface Extension
Network Services Extension
307-131 I, II, III (all three volumes)
The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders: mail orders
should include a check or money order, payable to AT&T.
The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.
The X/OPEN Group is "Ten of the world's major information system
suppliers" (at time of publication, Bull, DEC, Ericsson, Hewlett-Packard,
ICL, NIXDORF, Olivetti, Philips, Siemens and Unisys and subsequently
augmented by AT&T) who have produced a document intended to promote
the writing of portable applications. They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.
The book is published by
Elsevier Science Publishers B.V.
Book Order Department
P.O. Box 1991
1000 BZ Amsterdam
The Netherlands
and distributed in the U.S.A. and Canada by:
Elsevier Science Publishing Company, Inc.
52 Vanderbilt Avenue
New York, NY 10017
U.S.A.
There are currently five volumes:
1) System V Specification Commands and Utilities
2) System V Specification System Calls and Libraries
3) System V Specification Supplementary Definitions
4) Programming Languages
5) Data Management
They take a large number of credit cards and other forms of payment.
Comments, suggestions, error reports, etc., for Issue 2 of the Green Book
may be mailed directly to:
xpg2@xopen.co.uk
uunet!mcvax!inset!xopen!xpg2
Information about X/OPEN can be requested from:
Mike Lambert
Technical Director
X/OPEN Ltd
c/o ICL BRA01
Lovelace Road
Bracknell
Berkshire
England
+44 344 42 48 42
mgl@xopen.co.uk
uunet!mcvax!inset!xopen!mgl
Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:
Howard Press
c/o USENIX Association
P.O. Box 2299
Berkeley, CA 94710
415-528-8649
{ucbvax,decvax}!usenix!office
4.3BSD User's Manual Set (3 volumes) $25.00
User's Reference Manual
User's Supplementary Documents
Master Index
4.3BSD Programmer's Manual Set (3 volumes) $25.00
Programmer's Reference Maual
Programmer's Supplementary Documents, Volume 1
Programmer's Supplementary Documents, Volume 2
4.3BSD System Manager's Manual (1 volume) $10.00
Unfortunately, there are some license restrictions.
Contact the USENIX office for details.
Volume-Number: Volume 12, Number 31
From jsq Fri Jan 15 12:23:08 1988
Received: by uunet.UU.NET (5.54/1.14)
id AA03521; Fri, 15 Jan 88 12:23:08 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <5163@uunet.UU.NET>
Date: 15 Jan 88 17:22:50 GMT
Apparently-To: std-unix-archive
This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.
Corrections and additions to this article are solicited.
Access information is given in this article for the following:
user groups: USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG, DECUS
journal: Computing Systems
newsletters: ;login:, CommUNIXations, /usr/digest, EUUGN, AUUGN, NUZ
magazines: UNIX REVIEW, UNIX/WORLD, IX Magazine,
UNIX Systems, UNIX Magazine
Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.
UNIX is a Registered Trademark of AT&T.
USENIX is ``The Professional and Technical UNIX(R) Association.''
USENIX Association
P.O. Box 2299
Berkeley, CA 94710
U.S.A.
+1-415-528-8649
{uunet,ucbvax,decvax}!usenix!office
office@usenix.org
USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:
Feb 9-12 1988 Grand Kempinski Hotel, Dallas, TX, concurrent w/UniForum
Jun 20-24 1988 Hilton Hotel, San Francisco, CA
Jan 31-Feb 3 1989 Town & Country Inn, San Diego, CA
Jun 12-16 1989 Hyatt Regency, Baltimore, MD
Jan 23-26 1990 Washington, DC
Jun 11-15 1990 Marriott Hotel, Anaheim, CA
Jan 22-25 1991 Dallas
Jun 10-14 1991 Opryland, Nashville
They also sponsor workshops, such as
May 12-13 1988 Omni Shoreham Hotel, Washington, DC
Fifth Workshop on Real-Time Software and Operating Systems
IEEE Computer Society and USENIX Association
Aug 29-30 1988 UNIX Security, Portland, OR
Sep 26-27 1988 UNIX & Supercomputing, Pittsburgh, PA
Oct 17-20 1988 C++ Conference (tentative), Denver, CO
Nov 17-18 1988 Large Installation System Administration II, Monterey,CA
Proceedings for all conferences and workshops are available at
the door and by mail later.
USENIX publishes ``;login: The USENIX Association Newsletter''
bimonthly. It is sent free of charge to all their members and
includes technical papers. There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.
In 1988, USENIX will start publishing a new refereed quarterly
technical journal, ``Computing Systems: The Journal of the USENIX
Association,'' in cooperation with University of California Press.
They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership. They distribute tapes of contributed software and are
pursuing expanding that activity.
There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.
/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.
/usr/group
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
U.S.A.
tel: +1-408-986-8840
fax: +1-408-986-1645
The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.
Feb 8-11 1988 Infomart, Dallas, TX, concurrent with USENIX
Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
Jan 23-26 1990 Washington Hilton, Washington, DC
Jan 22-25 1991 Infomart, Dallas, TX
Jan 21-24 1992 Moscone Center, San Francisco CA (tentative)
They also sponsor a regional show, UniForum D.C.:
Aug 2-4 1988 Washington Hilton Hotel, Washington, D.C.
Proceedings for all conferences are available at the shows and later
by mail.
/usr/group publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.
/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group. This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.
/usr/group has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Technical Committee
on areas that P1003 has not yet addressed. They have recently produced
an overview of the POSIX standard, ``POSIX Explored,'' and funded production
of a draft of a ``Rationale and Notes'' appendix for that standard.
EUUG is the European UNIX systems Users Group.
EUUG secretariat
Owles Hall
Buntingford
Herts SG9 9PL
England
Telephone +44 763 73039
Telefax +44 763 73260
uunet!mcvax!inset!euug
euug@inset.co.uk
They have a newsletter, EUUGN, and hold two conferences a year.
The next one is in London, England, 11-15 April 1988, followed by
Lisbon, Portugal, in October.
AUUG is the Australian UNIX systems Users Group.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
Phone contact can occasionally be made at +61 3 344 5225
AUUG holds biennial conferences, usually of 2 days each.
The next meeting is in February 1987.
They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.
The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
(in June this year), and publishes a newsletter, ``NUZ.''
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
The Korean UNIX User Group has a software distribution service and a newsletter.
Korean UNIX User Group
ETRI
P.O. Box 8
Daedug Science Town
Chungnam 300-32
Republic of Korea
+82-042-822-4455
The Japan UNIX Society has two meetings a year, and a newsletter.
Japan UNIX Society
#505 Towa-Hanzomon Corp. Bldg.
2-12 Hayabusa-cho
Chiyoda-ku, Tokyo 102
Japan
+81-03-234-2611
There are similar groups in other parts of the world. If such a group
wishes to be included in later versions of this access list, they
should please send me information.
There is a partial list of national organizations in the November/December
1987 CommUNIXations.
Also, DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) which participates
in its meetings, which are held twice a year.
DECUS U.S. Chapter
219 Boston Post Road, BP02
Marlboro, Massachusetts 01752-1850
U.S.A.
+1-617-480-3418
See also the USENET newsgroup comp.org.decus.
The main general circulation (more than 10,000 copies per issue) magazines
about the UNIX system are
UNIX REVIEW UNIX/WORLD
Miller Freeman Publications Co. Tech Valley Publishing
500 Howard Street 444 Castro St.
San Francisco, CA 94105 Mountain View, CA 94041
U.S.A. U.S.A.
+1-415-397-1881 +1-415-940-1500
IX Magazine UNIX Systems
Storyplace Ltd. Eaglehead Publishing Ltd.
137-139 Euston Road Maybury Road
London NW1 2AU Woking, Surrey GU21 5HX
England England
+44-48-6227661
UNIX Magazine
Jouji Ohkubo
c/o ASCII Corp.
jou-o@ascii.junet
+81-3-486-4523
fax: +81-3-486-4520
telex: 242-6875 ASCIIJ
Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters. The following
information about bookstores was taken from the same issue. In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.
Computer Literacy Bookshop UNIX Book Service
2590 No. First St. 35 Bermuda Terrace
San Jose, CA 95131 Cambridge, CB4 3LD
U.S.A. England
+1-408-4350-1118 +44-223-313273
Cucumber Bookshop Jim Joyce's UNIX Book Store
5611 Kraft Ave. 47 Potomac St.
Rockville, MD 20852 San Francisco, CA 94117
U.S.A. U.S.A.
+1-301-881-2722 +1-415-626-7581
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Reply-To: std-unix@uunet.UU.NET
This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.
Corrections and additions to this article are solicited.
Access information is given in this article for the following:
user groups: USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG,
DECUS UNIX SIG, Sun User Group
newsletters: ;login:, /usr/digest, EUUGN, AUUGN, NUZ
journal: Computing Systems
magazines: CommUNIXations, UNIX REVIEW, UNIX/WORLD, IX Magazine,
UNIX Systems, UNIX Magazine
Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.
UNIX is a Registered Trademark of AT&T.
USENIX is ``The Professional and Technical UNIX(R) Association.''
USENIX Association
P.O. Box 2299
Berkeley, CA 94710
U.S.A.
+1-415-528-8649
{uunet,ucbvax,decvax}!usenix!office
office@usenix.org
USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:
Feb 10-12 1988 Grand Kempinski Hotel, Dallas, TX, concurrent w/UniForum
Jun 21-24 1988 Hilton Hotel, San Francisco, CA
Feb 1- 3 1989 Town and Country Hotel, San Diego, CA
Jun 13-16 1989 Hyatt Regency, Baltimore, MD
Jun 11-15 1990 Marriott Hotel, Anaheim, CA
They also sponsor workshops, such as
May 12-13 1988 Omni Shoreham Hotel, Washington, DC
Fifth Workshop on Real-Time Software and Operating Systems
IEEE Computer Society and USENIX Association
Proceedings for all conferences and workshops are available at
the door and by mail later.
USENIX publishes ``;login: The USENIX Association Newsletter''
bimonthly. It is sent free of charge to all their members and
includes technical papers. There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.
In 1988, USENIX will start publishing a new refereed quarterly
technical journal, ``Computing Systems: The Journal of the USENIX
Association,'' in cooperation with University of California Press.
They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership. They distribute tapes of contributed software and are
pursuing expanding that activity.
There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.
/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.
/usr/group
4655 Old Ironsides Drive, Suite 200
Santa Clara, California 95054
U.S.A.
tel: +1-408-986-8840
fax: +1-408-986-1645
The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.
Feb 8-11 1988 Infomart, Dallas, TX, concurrent with USENIX
Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
Jan 23-26 1990 Washington Hilton, Washington, DC
Jan 22-25 1991 Infomart, Dallas, TX
Jan 21-24 1992 Moscone Center, San Francisco CA (tentative)
They also sponsor a regional show, UniForum D.C.:
Aug 2-4 1988 Washington Hilton Hotel, Washington, D.C.
Proceedings for all conferences are available at the shows and later
by mail.
/usr/group publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.
/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group. This newsletter covers
product announcements and industry projections, and is sent biweekly
to General members of /usr/group and to non-member subscribers.
/usr/group has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Technical Committee
on areas that P1003 has not yet addressed. They have recently produced
an executive summary, ``Your Guide to POSIX,'' and a technical overview
``POSIX Explored,'' and funded production of a draft of a ``Rationale and
Notes'' appendix for IEEE 1003.1.
EUUG is the European UNIX systems Users Group.
EUUG secretariat
Owles Hall
Buntingford
Herts SG9 9PL
England
Telephone +44 763 73039
Telefax +44 763 73255
uunet!mcvax!inset!euug
euug@inset.co.uk
They have a newsletter, EUUGN, and hold two conferences a year:
11-15 April 1988, London, England
3-7 October 1988, Lisbon, Portugal
AUUG is the Australian UNIX systems Users Group.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
Phone contact can occasionally be made at +61 3 344 5225
AUUG holds at least one conference a year, usually in the spring
(August or September). The next one will be in Melbourne on 13-15
September 1988, will be the first three day meeting, will have a larger
equipment exhibition than any before, and will be professionally
organized for the first time.
They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.
The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
(in June this year), and publishes a newsletter, ``NUZ.''
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
The Korean UNIX User Group has a software distribution service and a newsletter.
Korean UNIX User Group
ETRI
P.O. Box 8
Daedug Science Town
Chungnam 300-32
Republic of Korea
+82-042-822-4455
The Japan UNIX Society has two meetings a year, and a newsletter.
Japan UNIX Society
#505 Towa-Hanzomon Corp. Bldg.
2-12 Hayabusa-cho
Chiyoda-ku, Tokyo 102
Japan
+81-03-234-2611
There are similar groups in other parts of the world. If such a group
wishes to be included in later versions of this access list, they
should please send me information.
There is a partial list of national organizations in the November/December
1987 CommUNIXations.
DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held twice a year.
DECUS U.S. Chapter
219 Boston Post Road, BP02
Marlboro, Massachusetts 01752-1850
U.S.A.
+1-617-480-3418
See also the USENET newsgroup comp.org.decus.
The Sun User Group (SUG) is an international organization that promotes
communication among Sun users, OEMs, third party vendors, and Sun
Microsystems, Inc. SUG sponsors conferences, collects and distributes
software, produces the README newsletter and T-shirts, sponsors local
user groups, and communicates members' problems to Sun employees and
management.
Sun Microsystems User Group, Inc.
2550 Garcia Avenue
Mountain View, CA 94043
U.S.A.
+1 415 960 1300
users@sun.com
sun!users
They have not set a date/location for the 1988 conference yet, but are
actively looking for a hotel (with good pricing and lots of room).
They've narrowed it down to several locations - Miami/Tampa Florida,
Houston/Dallas Texas, and New Orleans LA. The date will probably be
very early December, 1988.
The main general circulation (more than 10,000 copies per issue) magazines
about the UNIX system are
UNIX REVIEW UNIX/WORLD
Miller Freeman Publications Co. Tech Valley Publishing
500 Howard Street 444 Castro St.
San Francisco, CA 94105 Mountain View, CA 94041
U.S.A. U.S.A.
+1-415-397-1881 +1-415-940-1500
IX Magazine UNIX Systems
Storyplace Ltd. Eaglehead Publishing Ltd.
137-139 Euston Road Maybury Road
London NW1 2AU Woking, Surrey GU21 5HX
England England
+44 1 380 1510 +44 48 622 7661
UNIX Magazine
Jouji Ohkubo
c/o ASCII Corp.
jou-o@ascii.junet
+81-3-486-4523
fax: +81-3-486-4520
telex: 242-6875 ASCIIJ
In addition:
Computing Systems CommUNIXations
USENIX Association /usr/group
P.O. Box 2299 4655 Old Ironsides Drive, Suite 200
Berkeley, CA 94710 Santa Clara, California 95054
U.S.A. U.S.A.
+1-415-528-8649 +1-408-986-8840
Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters. The following
information about bookstores was taken from the same issue. In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.
Computer Literacy Bookshop UNIX Book Service
2590 No. First St. 35 Bermuda Terrace
San Jose, CA 95131 Cambridge, CB4 3LD
U.S.A. England
+1-408-4350-1118 +44-223-313273
Cucumber Bookshop Jim Joyce's UNIX Book Store
5611 Kraft Ave. 47 Potomac St.
Rockville, MD 20852 San Francisco, CA 94117
U.S.A. U.S.A.
+1-301-881-2722 +1-415-626-7581
Volume-Number: Volume 12, Number 32
From jsq Fri Jan 15 12:25:09 1988
Received: by uunet.UU.NET (5.54/1.14)
id AA03647; Fri, 15 Jan 88 12:25:09 EST
From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: calendar of UNIX-related events
Message-Id: <5164@uunet.UU.NET>
Date: 15 Jan 88 17:24:57 GMT
Apparently-To: std-unix-archive
Here is a combined calendar of planned conferences, workshops, or
standards meetings by various organizations. I compiled it for
my own use and thought it might be of some public worth. Most of
this information came from the various conference organizers,
although some was taken from ;login: (USENIX), 13, 1, Jan/Feb
1988 and CommUNIXations (/usr/group), VII, 6, Nov/Dec 1987.
Abbreviations: U for UNIX, W for Workshop, C for Center. The
sponsors of the USENIX, EUUG, and AUUG conferences are the
organizations of the same name, and the sponsor of UniForum is
/usr/group. Dates and places for IEEE 1003 after Oct 1988 are
tentative, and also for the 1992 UniForum.
year mon days conference name (sponsor,) (hotel,) location
1988 Feb 8-11 UniForum Infomart, Dallas, TX
1988 Feb 9-12 USENIX Grand Kempinski, Dallas, TX
1988 Mar 14-18 IEEE 1003 Ritz-Carlton, Washington, DC
1988 Apr 11-15 EUUG QE II Conference C, London
1988 May 3-5 U Exposition AFUU, Palais des Congress, Paris
1988 May 12-13 Real-Time W USENIX/IEEE, Omni Shoreham, Washington
1988 May 17-19 UNIX 88/etc. /usr/group/cdn, Convention C, Toronto
1988 Jun 7-9 COMUNIX /usr/group/UK, Alexandra Palace, London
1988 Jun 20-24 USENIX Hilton, San Francisco, CA
1988 Jun 27-Jul 1 IEEE 1003 Colorado Springs, CO
1988 Jun UNIX 88 NZSUGI, Wellington, New Zealand
1988 Jul U Symposium JUS, Tokyo, Japan
1988 Aug 2-4 UniForum/DC Washington Hilton, Washington, DC
1988 Aug 29-30 U Security W USENIX, Portland, OR
1988 Sep 13-15 AUUG Melbourne, Australia
1988 Sep 26-27 U&Supercomputing W USENIX, Pittsburgh, PA
1988 Oct 3-7 EUUG Lisbon, Portugal
1988 Oct 10-14 IEEE 1003 Hawaii
1988 Oct 17-19+ ISO SC22 & WG15 Tokyo, Japan
1988 Oct 17-21 C++ Conference USENIX, Denver, CO
1988 Oct UNIX Expo New York, NY
1988 Nov 17-18 Large Installation Syst. Adm. W II, USENIX, Monterey, CA
1988 Nov U Symposium JUS, Osaka, Japan
1988 Dec Sun User Group southern U.S.A.
1988 Dec UNIX Fair JUS, Tokyo, Japan
1989 Jan IEEE 1003 Ft. Lauderdale, FL
1989 Jan 31-Feb 3 USENIX Town and Country, San Diego, CA
1989 Feb 28-Mar 3 UniForum Moscone Center, San Francisco, CA
1989 Apr IEEE 1003 Minneapolis-St. Paul, MN
1989 Jun 12-16 USENIX Hyatt Regency, Baltimore, MD
1989 Jun IEEE 1003 Monterey, CA
1989 Oct IEEE 1003 Brussels (or Amsterdam)
1990 Jan 23-26 USENIX Washington, DC
1990 Jan 23-26 UniForum Washington Hilton, Washington, DC
1990 Jan IEEE 1003 New Orleans, LA
1990 Jun 11-15 USENIX Marriott, Anaheim, CA
1991 Jan 22-25 USENIX Dallas, TX
1991 Jan 22-25 UniForum Infomart, Dallas, TX
1991 Jun 10-14 USENIX Opryland, Nashville, TN
1992 Jan 21-24 UniForum (?) Moscone Center, San Francisco CA
Volume-Number: Volume 12, Number 33
From std-unix Sat Jan 23 14:24:31 EST 1988
Article 104 of comp.std.unix:
Path: uunet!std-unix
>From: std-unix@uunet.UU.NET (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End of Volume 12
Message-ID: <5327@uunet.UU.NET>
Date: 20 Jan 88 23:20:39 GMT
Reply-To: std-unix@uunet.uu.net
Lines: 4
Approved: jsq@uunet.uu.net (Moderator, John S. Quarterman)
This is the last article in Volume 12 of comp.std.unix/std-unix@uunet.uu.net.
Volume 13 will begin immediately.
Volume-Number: Volume 12, Number 34