Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/mod.std.unix.v4

Internet Message Format | 1987-06-30 | 56KB

From jsq  Wed Nov 27 21:15:55 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: V4N1; mod.std.unix Volume 4
Message-Id: <[e-mail]>
Date: 28 Nov 85 03:15:49 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 37
Approved: [e-mail]
Draft-9: mod.std.unix

This is the first article in Volume 4 of mod.std.unix/std-unix.
The new volume is strictly for administrative convenience, as
I am about to post information on how to get P1003 Draft 6 and
if that's at the beginning of a volume people will find it more
easily when I tell them to ftp the volume.

Feel free to continue any discussions from the previous volume,
or to start new ones.


The USENET newsgroup mod.std.unix is for discussions of UNIX standards,
particularly the IEEE P1003 draft standard.  It is also distributed
in an ARPA Internet mailing list.  I'm the moderator, which mostly
means I post what you send me.

Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix

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 sally.UTEXAS.EDU.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
as ~ftp/pub/mod.std.unix, while the previous volumes may be retrieved
as ~ftp/pub/mod.std.unix.v1 and ~ftp/pub/mod.std.unix.v2.
The volume with the AT&T public domain getopt(3) is ~ftp/pub/mod.std.unix.v3.

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 the standard) of the committee as a
whole, unless explicitly stated otherwise in such remarks.

Volume-Number: Volume 4, Number 1

From jsq  Wed Nov 27 21:53:42 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: V4N2; P1003.D6
Message-Id: <[e-mail]>
Date: 28 Nov 85 03:53:35 GMT
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 66
Approved: [e-mail]
Draft-9: D6.Access

An online document which "represents" P1003 Draft 6 is on sally.UTEXAS.EDU,
for retrieval by anonymous ftp (connect with ftp, log in as anonymous
with password guest) over the ARPA Internet.  The files are:

-rw-r--r--  1 jsq      bin        419840 Nov 27 21:48 ~ftp/pub/P1003.D6
-rw-r--r--  1 jsq      bin        376814 Nov 27 21:50 ~ftp/pub/P1003.D6.doc
-rw-r--r--  1 uucp     uucp       141981 Nov 22 17:37 ~ftp/pub/P1003.D6.Z
-rw-r--r--  1 uucp     uucp       124055 Nov 24 01:31 ~ftp/pub/P1003.D6.doc.Z

P1003.D6 is a tar archive of the source for the document.
P1003.D6.doc is an nroff formatted copy of the document, suitable
    for printing on a line printer (contains form feeds and backspaces).
P1003.D6.Z and P1003.D6.doc.Z are compressed copies of the above files.
They were compressed with compress version 4, a public domain program
which has been distributed over newsgroup net.sources on USENET.
There is a copy on sally.UTEXAS.EDU in ~ftp/pub/compress.shar.

The list of hosts which previously made Draft 5 available are
sally.UTEXAS.EDU, as above; on UUCP:  ut-sally (contact ut-sally!jsq),
decvax (contact decvax!jmcg), l5, seismo, ucbvax, munnari, and enea.
Presumably they will all pick up at least the compressed files.

Those of you who have asked for copies by UUCP mail:  I've found
a method; please contact me again if you're still interested.
If you're on the ARPA Internet you should use ftp.

The rest of this article is a note which appears in the document:


This online document represents, but IS NOT, the current DRAFT (Draft 6,
produced 15 November 1985) of the IEEE Computer Society's P1003 Working
Group for a "Portable Operating System Environment" based on the UNIX
Operating System (Trademark of AT&T Bell Laboratories).

This material is copyright of IEEE, with ALL RIGHTS RESERVED.  Please
respect these restrictions so we can continue to offer on-line access to
the information.

If you want to join the Correspondent Group (don't expect to make
meetings), the Working Group, or Balloting group for this standards
effort please contact:

     Jim Isaak             decvax!frog!jim
     Charles River Data Systems
     983 Concord Street
     Framingham, MA  01701.

(Jim needs your US Mail address to send you information about the effort;
he also needs your IEEE Membership Number if you wish to join the Balloting
Group).

Draft 6 was prepared for the Trial Use Balloting now taking place, with
a final use ballot some time near the end of 1986.

A moderated USENET group exists for on-line discussion of this effort
under the name: mod.std.unix

If you want hard copies of the DRAFT, you can obtain these from:

    Beth Cummings
    IEEE Standards Office;
    345 E. 47th Street
    New York, NY  10017


Volume-Number: Volume 4, Number 2

From jsq  Sun Dec  1 17:29:44 1985
Path: ut-sally!std-unix
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: V4N2; V4N3: P1003.D6 run script problem
Message-Id: <[e-mail]>
Date: 1 Dec 85 17:29:44 GMT
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 33
Summary: run script was broken:  here's a working one
Approved: [e-mail]
Draft-9: D6.Access

The run script in P1003.D6.Z refers to "$HOME/bin/fixuptbl.sed",
which is used locally at decvax to convince their LN01 to draw
continuous vertical and horizontal rules.  It also uses the file
"respform".  In other words, it was a private script for decvax.
Here is a public version.  It also appears on sally.UTEXAS.EDU as

-rw-r--r--  1 jsq      bin           512 Dec  1 11:26 ~ftp/pub/P1003.D6.run

#! /bin/csh -f

# output/forew.pageno must be created by hand; it looks like
#
#    .nr XP 7 \" FOREWORD BEGINS
#
# where the 7 is the number of the first page following the table of contents
#
if( -e output/forew.pageno ) cat output/forew.pageno >output/tbl.o

soelim sect/ch* | tbl >>output/tbl.o

csh -c 'nice +1 time ditroff -rZ1 -t -Tln01 mmt ieee.macros output/tbl.o >output/draft6' >& output/index.raw

cd output

    ../index.tools/mkindex

    lpr -Pln -n -m index.ditroff.o draft6

    ../index.tools/updaterefs

exit

Volume-Number: Volume 4, Number 3

From [e-mail] Tue Dec  3 05:46:04 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits; V4N4
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Dec 85 11:22:26 GMT
Draft-9: 2.9

Date: Tue, 26 Nov 85 21:47:31 pst
From: topaz!packard!scgvaxd!trwrb!desint!geoff (Geoff Kuenning)

In article <[e-mail]> allegra!jpl (John P. Linderman) writes:

>2)  The kernel is a lousy place to store the limits.h information.
>    It is preposterous to have a separate system call for each
>    value.  If you return a structure that includes all the values,
>    you trash existing binaries whenever you make the returned
>    structure larger by adding another value.  If you use an index
>    to return a single value, you can only port to systems that
>    agree with you on the index values.

Both of these "problems" are easily solved non-problems;  nevertheless
I think I have been convinced that a file like /etc/limits (or some
such) is a superior solution on the principle of "don't put it in the
kernel unless you have to."

Talking about his proposed solution (posted with the article, John writes
that if you try out his
>program, you will recognize one problem.  It's slow.  I claim this is
>a non-problem: look up your values once, and then run nice and fast.

Give me a break, John.  Do you seriously expect me to wait for you to
run cc and sed every time I want to start up the editor?  I realize
that your program is a quick hack, but I don't think we can just
cavalierly write off startup time.  Most BSD users already run with
TERMCAP in their environment, solely as a kludge to get around the cost
of reading through /etc/termcap.  We need to remember that startup times
*are* important, and it is very expensive to open and read through even
a small file.
--

    Geoff Kuenning
    {hplabs,ihnp4}!trwrb!desint!geoff

Volume-Number: Volume 4, Number 4

From jsq  Thu Dec  5 11:14:58 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: re: limits; V4N5
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 5 Dec 85 17:14:09 GMT
Draft-9: 2.9

Date: Wed, 4 Dec 85 21:31:45 cst
From: allegra!jpl (John P. Linderman)

Geoff Kuenning ({hplabs,ihnp4}!trwrb!desint!geoff) raises some
interesting points.

> Have you every typed "show *" on VMS (or whatever the syntax is;  I'm
> glad to say I've forgotten)?  [Nope. jpl] You will get a list of literally
> *hundreds* of environment variables, most of which are absolutely
> necessary for the system to work properly.  The result is you can never
> find anything.
>
> It is *not* a good idea to cavalierly add variables to the environment.

Perhaps my posting was unclear.  The environment variable was to be used
to *override* values that were always present in limit.h or /etc/limits.
It is not necessary to use environment variables if you are willing to
live with the defaults.

> In the first place, it increases the cost of forking *and* exec-ing,

I have certainly heard this stated often enough, but I have never
really observed it.  Perhaps I run on larger machines, or have a
smaller environment.  If we are talking hundredths of a second, it isn't
worth discussing.  If we are talking seconds, I think your fork
and exec are broken.  Anybody have hard documentation on the effect
of environment size?

> in the second place every program has to provide for the variable, and

I draw a blank on this one.  The putative library routine that looks
up the values also handles the environment variable.  No other source
code cares.  This is in sharp distinction to alternatives such as
adding a command line argument to override default values.  This
approach really *does* make life complicated, not only because
every program must anticipate the command line argument, but also
because the argument must somehow get explicitly passed into every
exec instead of sliding silently along in the environment.

> in the third place it makes the user's life more difficult.  I'm already
> harassed enough by the size of my environment, thank you.

Sorry to hear that.  I hope it gets better.

> Talking about his proposed solution (posted with the article, John writes
> that if you try out his
> >program, you will recognize one problem.  It's slow.  I claim this is
> >a non-problem: look up your values once, and then run nice and fast.
>
> Give me a break, John.  Do you seriously expect me to wait for you to
> run cc and sed every time I want to start up the editor?  I realize
> that your program is a quick hack, but I don't think we can just
> cavalierly write off startup time.  Most BSD users already run with
> TERMCAP in their environment, solely as a kludge to get around the cost

I'm beginning to see why you are harassed by the size of you environment. :-)

> of reading through /etc/termcap.  We need to remember that startup times
> *are* important, and it is very expensive to open and read through even
> a small file.

I think this is a valid point, although the editor I use already opens
.exrc files in the current directory and my home directory, and
snuffles around in /etc/termcap and who knows what else.  Running the
preprocessor probably wouldn't slow it down much more.  I think Geoff
and I have different visions about what commands might use this
run-time lookup mechanism.  If we assume that the main reason for the
mechanism is to allow runtime lookup of critical values that may
reasonably be expected to vary between binary-compatible machines, then
the mechanism should be of no use to the vast majority of existing
commands.  What does echo need to know that is going to change from
machine to machine?  The applications I had in mind were large data
base applications or other special purpose routines that stressed the
limits of machine resources.  As Geoff points out, the mechanism is
not well suited to commands whose running times are very short.

Volume-Number: Volume 4, Number 5

From jsq  Thu Dec  5 18:05:25 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits; V4N6
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Dec 85 00:05:09 GMT
Draft-9: 2.9

Date: Thu, 5 Dec 85 16:45:19 cst
From: allegra!jpl (John P. Linderman)

I decided to do a little testing to see how much the size of my
environment affected response time.  I wrote the following korn shell
script, and ran in on an unloaded (but not singleuser) VAX 8600.  Each
main loop runs /bin/echo 1000 times, with exported variable ``a'' doubling
in size each time through the outer loop.  I unset as much as possible,
to minimize the environment, as the export at the start shows.  Adding
a seventh iteration to the outside loop made the environment too big.
All the commands in the inner loop except /bin/echo are shell builtins,
so there should be only one fork and exec per iteration.

#!/bin/ksh
a="`cat /etc/fstab`"
unset MAILCHECK RANDOM
export
export a
for i in 1 2 3 4 5 6
do
    export | /usr/ucb/wc
    /bin/date
    j=0
    while let "j = j + 1"  "j <= 1000"
    do
    /bin/echo abc > /dev/null
    done
    /bin/date
    a="$a
$a"
done

The results follow.

HOME=/
PWD=/
      10      10     181
Thu Dec  5 10:51:01 EST 1985
Thu Dec  5 10:52:12 EST 1985    ( 71 seconds)
      18      18     347
Thu Dec  5 10:52:13 EST 1985
Thu Dec  5 10:53:40 EST 1985    ( 87 seconds)
      34      34     679
Thu Dec  5 10:53:40 EST 1985
Thu Dec  5 10:55:11 EST 1985    ( 91 seconds)
      66      66    1343
Thu Dec  5 10:55:11 EST 1985
Thu Dec  5 10:56:59 EST 1985    (108 seconds)
     130     130    2671
Thu Dec  5 10:56:59 EST 1985
Thu Dec  5 10:59:02 EST 1985    (123 seconds)
     258     258    5327
Thu Dec  5 10:59:03 EST 1985
Thu Dec  5 11:02:35 EST 1985    (152 seconds)

There are many possible interpretations of the data, of which I am
certain we'll hear several.  I hadn't expected the size of the
environment to matter as much as it did, but the bottom line for me, on
my nice fast machine, is that the biggest environment I'm allowed to
carry around adds at most a tenth of a second to a fork+exec.  The
actual environment I carry around (about 900 bytes) adds somewhere
around 3 hundredths of a second to that cost.  I simply don't execute
enough processes in a day for that to make a difference.  On a slower
machine, my interpretation might be different.  I'd be curious to
see the results of a similar test on other machines.

John P. Linderman   Environmental Studies Department  allegra!jpl

Volume-Number: Volume 4, Number 6

From jsq  Mon Dec  9 15:13:47 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits; V4N7
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 9 Dec 85 21:13:23 GMT
Draft-9: 2.9

From: harvard!wjh12!panda!teddy!jpn (John P. Nelson)
Date: Mon, 9 Dec 85 11:35:09 est

>I decided to do a little testing to see how much the size of my
>environment affected response time.
>

I suspected that the iteration time was affected by the shell searching the
environment, rather than an increase in fork/exec time.  I wrote a C program
to do the same thing as the shell script written by John P. Linderman.  I
was wrong!

The following results were achieved on a diskless SUN-2 workstation (a
"perfmeter" running along side indicated 100% cpu usage, and 0% ethernet
activity - apparently everything remained in memory) I would have used a VAX,
but didn't want to annoy my fellow employees).  Your numbers will vary:

% testit
Env size 56, loop time 135
Env size 113, loop time 139
Env size 227, loop time 158
Env size 455, loop time 167
Env size 911, loop time 207
Env size 1823, loop time 292
Env size 3647, loop time 470
Env size 7295, loop time 846
fork or exec failure: terminating


John P. Nelson (decvax!genrad!teddy!jpn seismo!harvard!talcott!panda!teddy!jpn)

--- cut here.  testit.c follows: ---
#include <stdio.h>

char *env[2];
char *echoargv[] =
    {
    "echo",
    "abc",
    (char *) 0
    };

#define DEFAULTENV "TEST=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
#define INNERLOOP 1000

main()
    {
    extern char *malloc(), *realloc();
    register int i;
    register char *ptr;
    long starttime;
    long endtime;
    int waitst;

    env[0] = malloc(sizeof(DEFAULTENV));
    strcpy(env[0], DEFAULTENV);
    env[1] = 0;
    close(1);            /* close up stdout */
    if (open("/dev/null", 2) < 0)
    {
    fprintf(stderr, "Can't open /dev/null on 1\n");
    }

    while (1)    /* or until failure */
    {
    time(&starttime);
    for (i = 0; i < INNERLOOP; ++i)
        {
        /* do the fork/exec */
        if (fork() == 0)
        {
        execve("/bin/echo", echoargv, env);
        exit(-1);        /* exec failure */
        }

        /* terminate on anything but successfull exit(0) */
        if (wait(&waitst) < 0 || (waitst & 0xFFFF) != 0)
        {
        fprintf(stderr, "fork or exec failure: terminating\n");
        exit(0);
        }
        }
    time(&endtime);
    fprintf(stderr, "Env size %d, loop time %ld\n",
        strlen(env[0]), endtime - starttime);
    /* now double the environment size */
    env[0] = realloc(env[0], (strlen(env[0])+1) * 2);
    ptr = env[0] + strlen(env[0]);        /* point to trailing null */
    strcpy(ptr+1, env[0]);            /* tack on another copy */
    *ptr = '\n';                /* and join the two strings */
    }
    /* NOTREACHED */
    }

Volume-Number: Volume 4, Number 7

From jsq  Mon Dec  9 22:53:22 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: limits; V4N8
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 10 Dec 85 04:53:07 GMT
Draft-9: 2.9

From: seismo!gatech!hplabs!fortune!mats (Mats Wichmann)
Date: Monday,  9 Dec 1985 14:28-PST

The size of the environment certainly matters to fork/exec; the
reason is that all that data in user space has to be transferred
to kernel space somehow, then copied back out as part of the new
process. This is typically done through a series of fubyte()
calls, which vary in inefficiency with the type of MMU being
used in the machine. For someone running, say, a Motorola 68451
there is a horrible cost because the kernel has to do a lot
of calculation before knowing the virtual-to-physical translation
(Although by being clever and "caching" translations you can speed
it up quite a bit). Other MMUs make it easier - I think the VAX
scheme is a major improvement (although I am not intimately
familiar with it) and the Motorola 68851 is even better, and if
I am not mistaken, the National MMU chips even have an instruction
which basically moves data between user space and kernel space.

Whatever the exact numbers, transporting environments (and argument
lists, for that matter) across execs is a costly operation compared
to most others.

    Mats Wichmann
    Fortune Systems
    {ihnp4,hplabs,dual}!fortune!mats

Volume-Number: Volume 4, Number 8

From jsq  Wed Dec 11 11:19:59 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: In which gnu dissects the "tar" section of Draft 6; V4N9.
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 11 Dec 85 17:19:38 GMT
Draft-9: 10.0

Date: Wed, 11 Dec 85 00:32:33 PST
From: l5![e-mail] (John Gilmore)

Section 10.1.1 introduces the terms "interpret" and "translate" for
"load" and "dump".  Can we just use the familiar terms?  I have trouble
remembering which is which.

[ I think using either of the words "dump" or "restore" (the latter
actually used in the section) is a mistake, since they also connote
a completely different set of programs than those usually associated
with the format in question.  -mod ]

This section also says:
> "The format-interpreting utility is defined such that if it is not a
> privileged program, when data is read into the system from the
> transportable media, all protection information is ignored.  Instead the
> user ownership and group owership are set to that of the process context
> which is running the utility.  All access protection information can be
> set to be no more liberal than that of the process that is running the
> utility.  A privileged version of the utility must have as a minimum, an
> option that obeys the protection information stored on the transportable
> media, such that this format and the corresponding utility can be used as
> a save/restore mechanism."

First, this is self-contradictory; it says all protection information
is ignored, then says it can be set "no more liberal" than the
process.

[ The utility is not prevented from reading anything in the data
because of any protections associated with it.  However, once the
utility converts the data into files in the file system, there *is*
protection associated with it, as with any file:  the utility must
set the appropriate protection bits.  -mod ]

(I would assume the OS takes care of not letting your process
set protection more liberal than its own, else there is no security.)
I think what it means is that it's not legal for system V "tar" to always
chown away the files, which you can't get back.

[ Cpio actually does that under System V.  Such chowning is a major
security problem, much like your phrase:  "there is no security",
since the numeric user ids on the "tape" may have completely different
meanings on the system where it is being read than on the one where
it was written.  This problem has been addressed in several other places
in the standard as well as here.  -mod ]

Was there some other reason for this paragraph?  If not, can we replace
the text with something like:

  "The format-loading utility must not set access protections that cannot
  be revoked by the user running the utility (whether the user is
  privileged or not).  If it can be run as a privileged utility, an
  option (or default behaviour) must exist which obeys all the loaded
  protection information, so it can be used for system backups."

---

Also, section 10.1.2 uses confusing terminology with regard to blocks
and records.  In the data processing world, a block is a big thing and
one or more records fit in it (roughly speaking).  Like you write 100
records 80 chars long in an 8000 byte block on tape.  Has anybody
checked the ANSI standard for tape format to see what they call 'em?
The Unix standard uses "block" for the small records, "group" for the
large things, and also mentions that a "group" might turn into a single
tape "record".

I also don't see the need for two records of zeros on the end.  One
should be fine, and it won't break compatability with the Unix tar
program, which quits as soon as it sees the first one.  Tar should
really use EOF rather than this funny end of tape record; this would
solve two or three minor problems with it, but would break
compatability with existing Unix "tar".  (The problems:  the tape is
positioned wrong after reading a tar archive from a multi-file tape,
since the tape mark has not yet been read; you can't just concatenate
tar archives to combine their contents (which would make multi-volume
tar handling somewhat easier too); extra data is written, which
makes it uneconomical to use a large, tape-efficient block size (like a
megabyte on streaming cartridge tapes, since this will waste up to a
megabyte of space on the tape).

What I suggest is that ANSI standard tar's should be required to work
OK when reading an archive terminated by EOF (short last block, then
zero length result from read()).  Suggested wording:

  An archive tape or file contains a series of records.  Each record is of
  size TRECORDSIZE (see below).  Although this format may be thought of as
  being on magnetic tape, this does not exclude the use of other
  media.  Each file archived is represented by a header record
  which describes the file, followed by zero or more records which give the
  contents of the file.  At the end of the archive file there may be a record
  filled with binary zeros as an end-of-file indicator.  A conforming
  system must write a record of zeros at the end, but must not assume that
  an end-of-file record exists when reading an archive.

  The records may be blocked for physical I/O operations.  Each block of
  n records (where n is set by the application program creating the
  archive file) may be written with a single write() operation.  On
  magnetic tapes, the result of such a write is a single tape record.
  When writing an archive, the last block of records shall be written
  at the full size, with records after the zero record containing
  undefined data.  When reading an archive, a confirming system shall
  properly handle an archive whose last block is shorter than the rest.

This allows a system to provide an option to write more modern
archives, which will be readable by all P1003 conforming systems, but
requires that the default be compatible (readable with V7 Unix 'tar').

---

> /* Values used in typeflag field */
> #define REGTYPE   '0'         /* Regular file  */
> #define AREGTYPE  '\0'        /* Regular file  */
> #define LNKTYPE   '1'         /* Link          */
> #define SYMTYPE   '2'         /* Reserved      */
> #define CHRTYPE   '3'         /* Char. special */
> #define BLKTYPE   '4'         /* Block special */
> #define DIRTYPE   '5'         /* Directory     */
> #define FIFOTYPE  '6'         /* FIFO special  */
> #define CONTTYPE  '7'         /* Reserved      */

In the header file, less generic names than e.g. "REGTYPE" should be used.
How about "TF_REGULAR" (typeflag = regular file).  This avoids the well
known problem that a #define is a joy (or a pain) forever, especially
when some other header file wants to use the same name:

  /* The typeflag defines the type of file */
  #define    TF_OLDNORMAL    '\0'        /* Normal disk file, compat */
  #define    TF_NORMAL    '0'        /* Normal disk file */
  #define    TF_LINK        '1'        /* Link to dumped file */
  #define    TF_SYMLINK    '2'        /* Symbolic link */
  #define    TF_CHR        '3'        /* Character special file */
  #define    TF_BLK        '4'        /* Block special file */
  #define    TF_DIR        '5'        /* Directory */
  #define    TF_FIFO        '6'        /* FIFO special file */
  #define    TF_CONTIG    '7'        /* Contiguous file */
  /*
   * All other type values except A-Z are reserved for future standardization
   * and may not be used.  A-Z may be used for implementation-dependent
   * record types.
   */

The mode fields should use a prefix like "TM_" rather than just "T".
Also, TSVTX (the sticky bit) cannot be "reserved" otherwise implementations
cannot write archives that have it turned on.  Call it implementation-defined,
if you must.

> All characters are represented in ASCII, using 8-bit characters without
> parity.  Each field within the structure is contiguous; that is, there is
> no padding used within the structure.  Each character on the archive media
> is stored contiguously.

You'd better be more specific.  USASCII, with the 7-bit character in the
low-order 7 bits and the high-order bit cleared?  What about foreign
sites with funny characters in their file names?

> The fields name, linkname, magic, uname and gname are null-terminated
> character strings.

Does this mean that when writing an archive, you MUST put in the null,
or if the value exactly fills the field, is it OK to not have a null
there?  In other words, caveat writer or caveat reader?  Here again, a
prudent course would be to require the writer to do it right, and
require the reader to accept it either way.

> The mtime field is the modification time of the file at the time it was
> archived.  It is the ASCII representation of the octal value of the
> modification time obtained from the stat() call.

This should be spelled out in detail, so the definition of the archive
format can stand alone.

> ASCII digit `2' is reserved.
> ASCII digit `7' is reserved.
> ASCII letters `A' through `Z' are reserved for custom implementations.
> All other values are reserved for specification in future revisions of the
> standard.

As I understand standards, something that is reserved canNOT be used by
an implementation to extend the standard.  This is not the intention
here, since I presume compatability with BSD systems (which use 2 for
symlinks) is desired.  I'm not sure why we don't just standardize
symlinks here; after all, not all systems have fifos or contiguous
files either...

[ They were in there at one point.  I wonder what happened to them.  -mod ]

> The encoding of the header is designed to be portable across machines.

This sentence can go...

> 10.1.3  Notes
> ...
> Implementors should be aware that the previous file format did not include
> a mechanism to archive directory type files.  For this reason, the
> convention of using a file name which ended with a slash (/) was adopted
> to specify the archiving of a directory.

But ANSI standard systems are not required to read such a tape?  I think
they should be required to read it but not write it.


An additional point.  The standard does not specify what fields are defined
in what record types.  For example, is it OK to have garbage in the linkname
in record type 0 (normal files)?  Is it OK to put zeros in the uid/gid fields
if you have filled in the uname/gname/magic fields (say your system does not
have numeric uids?).  What about the bytes in the header records that
are not defined by the structure?  Or the bytes beyond the end of a file,
in its last record?  I'd suggest that we require these fields to be nulls
on writing, and require them to be ignored on reading, again for prudence.

Volume-Number: Volume 4, Number 9

From jsq  Wed Dec 11 15:47:59 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: size of environment vs speed; V4N10
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 11 Dec 85 21:47:45 GMT
Draft-9: 1003.2.environment

From: topaz!packard!mtung!jhc (Jonathan Clark)
Date: 11 Dec 85 14:03:32 EST (Wed)

While building fairly large pieces of software like an
entire UNIX system, kernel, commands, libraries, and
everything, from source, we found that a good way of
speeding everything up was to set up a minimum size
environment (about 5 variables), then use 'ksh' as the shell
that 'make' used all the time. This produced about a 1/4
faster build (knocked about 90 mins off a six-hour build
time). Of course, most of what 'make' does is 'exec' a
shell...

--
Jonathan Clark
[NAC]!mtung!jhc

My walk has become rather more silly lately.

Volume-Number: Volume 4, Number 10

From jsq  Thu Dec 12 13:59:24 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 Draft 6 -- Comments, criticisms etc.; V4N11
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Keywords: typos, consistency, other stuff
Date: 12 Dec 85 19:59:01 GMT
Draft-9: 2.3 2.5 2.7 2.8 2.9

Date: Wed, 11 Dec 85 17:06:10 EST
From: Arnold Robbins <[e-mail]>

Over a few nights, I sat down and read Draft 6 of the P1003 draft
standard.  Overall, it is really good, and the committee has done a
good job. Many of my comments are related to spelling, typographical,
and grammar errors. These are not important relative to the comment,
but should be cleaned up. The moderator should feel free to delete
those comments from what gets posted, as long as they get passed on to
the editor(s).

[ Might as well post them.  Besides, it's easier to pass things on
if they're all in one place.  -mod ]

The rest of my comments are just comments; something is referred to in
one place that was dropped elsewhere, or something left out, things of
that nature. Some of this should (I hope) stimulate good discussion.
Replies should probably go to the net, since I won't be here at Georgia
Tech for much longer.

I'll be posting several articles, to keep the size down, probably one
per chapter of the draft. Here is the Introduction, and Chapters 1 and 2.
Stuff quoted from the draft is indented, my comments are flush with the
left margin. The moderator should feel free to edit as he sees fit.

[ I've mostly just run fmt over stuff that wouldn't fit on 80 column
screens and added comments like this.  -mod ]

Arnold Robbins
CSNET:    arnold@gatech    ARPA:    [e-mail]
UUCP:    { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold
---------------------------
COVER PAGE:

    Prepared by the P1003 working group of the Operation System Standards...
                            ^^^^

Should be "Operating System"
         ^^^
FORWARD:
[ That's FOREWORD, i.e., a word that goes in front, not a direction to go in.
-mod ]
CHAPTER 1:
    No comments.

CHAPTER 2:
Sect 2.2:
    ... Non-standard extenstions
                  ^        (spelling error)

Sect 2.3 General Terms:

    Address Space
        The range of memory locations, both code and data, that
        can be referenced by a process.


Neither "code" nor "data" are defined anywhere. Is this one of those things
everyone knows what they are?
[ There's supposedly an IEEE dictionary of such things.  -mod ]

-----
    Process Lifetime
        ... When a process executes a _wait()_ primitive for an
        inactive process, ....

Should clarify that the inactive process can only be waited on by certain
processes (its ancestor(s)), not just any arbitrary process.

-----
    Parent Process ID

Should indicate that the parent process ID may change if the parent dies
before the child.

-----
    Real User ID and Real Group ID
        Each user is also a member of a group.

Should say something like "Each user is also a member of at least one group."
This helps with 4.2BSD systems.


        ... and real group ID. respectively, of the ...
                     ^

The period should be removed.
[ Should be a comma, actually.  -mod ]

-----
    Pipe

Should indicate that a pipe has the same behavior as a FIFO file for the
_close()_ primitive as well.


-----
    Directory

Should have an additional statement to the effect that directories are not
writable by normal user code; only system calls (_link()_, _mkdir()_, _rmdir()_,
etc., give a full list) shall be used to modify directory contents.

-----
    Root Directory and Current Working Directory
        ... A process's root directory need not be the root directory
        of the root file system.

What is the "root file system"? This isn't defined.
[ And we thought we'd rooted out all references to file systems.  :-) -mod ]

===========================================

Sect 2.4 Error Numbers:

    ENOENT    No such file or directory
        This error occurs when a file name is specified **and the file
        should exist but doesn't**, or when a directory in a path name
        does not exist.

The starred phrase just doesn't ring true. Maybe something like "but the file
does not exist" would be better. Who's to say whether or not the file "should"
exist?

===========================================

Sect 2.6 Environment Description:

    It is recommended the follwoing variable names....

Should be "It is recommended that the..."
                 ^^^^

===========================================

2.7 C Language Definitions

    A character is any bit pattern able to fit into a single byte.

"Byte" is left undefined here. Maybe it should be specified that it is
at least 8 bits?

===========================================

2.8 Numerical Limits

    {SYYS_OPEN}    Maximum number of files that can be open    16
            on the system at one tiime.

This number seems awfully small to me.
[ Historically accurate, though.  -mod ]

Volume-Number: Volume 4, Number 11

From jsq  Thu Dec 12 14:08:27 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 Draft 6, Chapters 3 and 4, comments; V4N12
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Dec 85 20:08:15 GMT
Draft-9: 3.1 3.2 3.3 4.1 4.2 4.4

Date: Wed, 11 Dec 85 17:20:01 EST
From: Arnold Robbins <[e-mail]>

Chapter 3: Process Primitives

Sect 3.1 Process Creation

    Running a program takes two steps...

Should be "Running a new program", i.e. some program other than what is now
running.  The paragraph implies that calling exec is mandatory; it isn't.

=====================================

Section 3.2.1.6 References (for the _wait()_ primitive)

Should include a reference to getppid() 4.4.1.

=====================================

Section 3.3.2.1 The Signal Function

    SIGDFL - signal specific default action
        ... Abnormal termination should result in the creation of a
        file named core in the receiving process's current directory.

"Core" should be quoted. Also, the file should be created only if the effective
uid has write permission in the directory.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Chapter 4.1 Process Identification

4.1.1.3 References (for getpid(), getpgrp(), getppid())

Should include a reference to wait(), 3.2.1.

---------------

4.2.3.2 Descriopion (of getlogin() and cuserid())

    ... or to call getlogin and, if it fails, to call the _getpwuid_ ...

The word "getlogin" should be italicized.

---------------

4.4.1.3.Returns (utsname)

    ... Otherwise, value of -1 is returned ...

Should be "Otherwise, a value of -1 ..."
             ^^^

Volume-Number: Volume 4, Number 12

From jsq  Thu Dec 12 14:16:09 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 Draft 6, Chapter 5, comments; V4N13
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Dec 85 20:15:56 GMT
Draft-9: 5.1 5.3.2 5.4.2 5.5.2 5.6

Date: Wed, 11 Dec 85 17:52:17 EST
From: Arnold Robbins <[e-mail]>

Chapter 5: Files, Directories, and File Systems

5.2.2 Directory Operations

While I am very pleased to see the BSD style directory access routines
included, I am dismayed at the lack of seekdir() and telldir(). These routines
are essential for traversing directory subtrees when one has a limited number of
open files allowed. Something should be done to try and included them.

---------

5.4.2.2. Description (of creat())

    ... If the file is a special file or a FIFO pipe, it is opened for
    writing.

Should be ".. or a FIFO file...".


A general note on _creat()_. It seems that whenever _open()_ is cited
in the references, _creat()_ is not. Either all the references should
be changed, or some note should be added explaining this. I don't think
that just stating that

    creat (path, mode)

is equivalent to

    open (path, O_WRONLY | O_CREAT | O_TRUNC, mode);

is enough. (Of course, I could be wrong....)

[ I'd think establishing that identity should be sufficient.  -mod ]

-----------

5.5.3.4 Errors (returned from mkfifo())

Why are EIO and ENFILE possible errors? EIO says "error writing to the
file system". ENOSPC (couldn't extend the directory) should handle
that. ENFILE seems to me to be wrong -- there is no reason to *open*
the file in order to create the fifo. mkfifo should just make a
directory entry and set the right bits in an inode (yeah I know, that
is an implementation thing). The point is that no files should be
opened here.

---------

5.6.2.4 Errors (for rmdir())

    [EBUSY]  The directory to be removed is the mount point for a
         mounted file system.

What is a mounted file system? I thought that all references to such things
had been removed.... This is probably just an oversight on the part of the
editor(s).

-----------

5.7.1.2 Description (of <stat.h>)

    S_IWXG    Read, write, and execute permissions for the group...

Should be S_IRWXG. This is undoubtedly a typo.


    S_ISUID    .....
        This bit shall be set only by the the function _chmod()_.
        It should be cleared on any open for writing.

    The word "the" is printed twice in the actual document. I did not
make a typo :-).  Also, I would prefer "It shall be cleared on any open for
writing".

    S_ISGID

Same comment about "should" vs. "shall".

[ Seems like the reason was that that would outlaw some existing systems. -mod ]

    st_ctime

Why does the pipe() system call change this field?

-----------

5.7.4.2 Description (of chmod())

    ... The value _chmod_ shall set the access permission portion of
    the named file's mode according to the bit pattern contained in mode.

Delete the first two words of this sentence and capitalize "chmod".

[ We never capitalize anything which is really in lower case,
even at the expense of filler words at the beginning of the sentence.  -mod ]

----------

5.7.5.2. Description (of chown())

Describes what happens to the setuid/setgid bits if successfully invoked
by a non-superuser (they're cleared). All fine and good, but what happens to
those bits if chown is invoked by the superuser? This should either be stated
clearly or explicitly left undefined or implementation dependant.

------------

5.7.6.5 Notes (on utime())

What about st_ctime? Most Unix implementations (all?) do not allow this
to be reset. Shouldn't something be said about it?

Volume-Number: Volume 4, Number 13

From jsq  Thu Dec 12 16:50:08 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 Draft 6, Chapters 6, 7, 8, and 9, comments; V4N14
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Dec 85 22:49:52 GMT
Draft-9: 6.2 6.4.1 8.2 9.2

Date: Thu, 12 Dec 85 09:28:06 EST
From: Arnold Robbins <[e-mail]>

Chanpter 6: Input and Output Primitives

6.2.1
    The functions _open()_ and _creat()_ assign file descriptors as
    well as having effects of creating a file on the file system...

Should be "as well as having effects of possibly creating a file.."
                    ^^^^^^^^
Creating a file every time isn't absolutely necessary.

------------------

6.3.1.4 Errors

The word "errrno" should be "errno" (two r's instead of three).

------------------

6.4.1.5 Notes (on dup and dup2)

    One of the options for the _fcntl()_ call operates in the same way
    as the _dup()_ call.

Should be dup2, not dup.

-------------------

6.6.1.2 Description (of read())

    ... or if the file is a pipe or special file.

Should probably be "is a pipe or character special file."

-------------------

6.7.2.2. Description (of fcntl())

    F_SETFL    Set _file_ status flags to value indicated by the third
        parameter, _arg_, taken as type _int_. Only the O_NDELAY
        and O_APPEND flags can set; see <fcntl.h> 6.7.1.

It occurred to me that also allowing O_TRUNC, taking effect at the current
position of the file pointer, would be a very easy way to implement the
4.2BSD truncate() call. This would also be upward compatible with current
System V, since it is currently illegal to use O_TRUNC in an fcntl() call,
so no (working) System V code would contain such a call. I hope that the
committee would consider this idea carefully.

==========================================================

Chapter 7: Device- and Class Specific Functions

    See Appendix C for provides alternatives being considered.

Delete the word "provides".

==========================================================

Chapter 8: C Language Library

8.1.3. Notes (on fileno())

    The _fileno_ function may be implemented as a macro and should not,
    therefore, be re-declared.

Add to the end of the sentence "or have its address taken".

===========================================================

Chapter 9: Passwords

9.1.2 Description (of group access routines)

    char **    gr_mem    Null-terminated vector of pointers to the
            individual member names.

Add "or numbers" to the end of this sentence.

----------------------


9.2.3 Description (of password file access routines)

    A NULL pointer is returned on error or the end of the database
    is encountered.

Should be "or when the end of the database..."

Volume-Number: Volume 4, Number 14

From jsq  Thu Dec 12 19:02:15 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 Draft 6, Chapter 10 and Appendices, comments; V4N15
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 13 Dec 85 01:01:52 GMT
Draft-9: 10.0 2.3 2.5 5.1 7.0 files.performance SVID

Date: Thu, 12 Dec 85 10:09:56 EST
From: Arnold Robbins <[e-mail]>

Chapter 10: Data Interchange Format

John Gilmore (l5!gnu) has already done a better job of commenting on this than I
could. I will note two spelling errors:

    The standard does not define the user interface to this program
    and notes that the format-interpreting and format-translating
    utilities need not be the same, thougt an implementor may chose
    to make them so.

"Thought" should be "though" and "chose" should be "choose"

===========================

Appendix A: Trial Use Areas of Comment

A.5 Media Formats

I don't think this really needs to be specified, but if the standard is
going to, then for 9 track 1/2 in. tape, the most portable format is
1600 BPI, "blocked" 10, i.e. 512 byte blocks * 10 blocks == 5K block
tape records.  This format tar tape is readable on basically any
machine, including the ATT 3B20s which have exceedingly brain-damaged
tape controllers (can't read any more than 6K off the raw tape device).

-----------

A.7.2 Error Number Validity

I like the proposed change for the third sentence of errno 2.4. This
solves the problems described.

===========================

Appendix C. Device Control and Terminal Characteristics.

    ... listed here with a request that it be review, ...

Should be "reviewed".

---------------------

C.1 I/octl/Iocntl/Termcnt Overview

    However, the definition of the terms would force low level concepts
    to be included a supposedly high level interface definition.

"to be included in a supposedly.."

---------------------

C.3.3 Problems (with current ioctl)

This section makes a big deal out of binary compatibility, but the standard
explicitly states in Chapter 1, Scope, that binary compatibility is not an
issue. If so, most of this section loses its validity.

---------------------

C.3.5 SVID Compatibility

It seems that the people who came up w/this don't know their C too well
either. Their definition

#define ioctl(a,b,c)    iocntl(a,b,c,sizeof(c))

should be

#define ioctl(a,b,c)    iocntl(a,b,c,sizeof(*(c)))

----------------------

C.7.2. Description (of <termios.h>

Discusses the _getty_ program actually opening the terminal devices and then
passing them on to _init_ and regular programs. Seems to me that neither
getty nor init are described anywhere else. For the real standard, this would
have to be cleaned up.

----------------------

C.7.2.6 Local Modes and Line Discipline

    ... These functions may be disabled individually by changing
    the value of the control character to an unlikely or meaningless
    value (e.g.  0377).

This is a nit, but it should be '\377', not 0377.

    When ICANON is set, the following echo functions are possible. Two
    fucntions are possible: those dealing....

Should be:

    When ICANON is set, the following two echo functions are possible:
    those dealing....

========================

Appendix I. Comparison to SVID Document.

I.2.12 Readdir

    struct dirent
        int_t d_ino

Should be "ino_t" instead of "int_t".

=========================

Appendix J. Proposed Definitions

J.2 General Terms

    Directory Entry
        A directory entry contains two items: a string whch is the
        filename and a file serial number.

Should be something more like:

    Directory Entry
        A directory entry contains at least two items: a string whch is
        the filename and a file serial number. Other, implementation-
        dependant items may also be included in the directory entry.

========================

Appendix K. Contiguous Files

K.5.1.2 Description (of allocf())

    O_CREAT    ....
        The ``save text image after execution bit'' of the mode
        is cleared. See _chmod()_.

The rest of the standard doesn't say anything about sticky bits.

K.5.1.4 Errors

    [ETXTBSY]    The file is a pure procedure (shared text) file
            that is being executed and _oflag_ is write
            or read/write.

This isn't in the rest of the standard.

Volume-Number: Volume 4, Number 15

From jsq  Thu Dec 12 20:33:48 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: A final comment on P1003 Draft 6; V4N16
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 13 Dec 85 02:33:34 GMT
Draft-9: IPC

Date: Thu, 12 Dec 85 13:25:12 EST
From: Arnold Robbins <[e-mail]>

Just a final note on the P1003 Draft. I am dismayed by the lack of any IPC
mechanism other than pipes and signals. While the draft explicitly says that
one should not use signals for interprocess communication, it is well known
that pipes and signals are not enough for the "real world".

I realize that the System V IPC mechanisms are usually considered
non-orthogonal and difficult to learn, and BSD sockets don't seem to be
general enough either.  But something should be done. It is hard to
both innovate and standardize at the same time, but some sort of IPC
should be added.

If this is an issue that has been purposely delayed, OK. As long as the
committee will acknowledge it as an issue, and eventually address it, I
won't say anything else.

[ You forgot FIFOs.  It's an acknowledged issue, yes.  -mod ]

I hope my comments have been useful.

Volume-Number: Volume 4, Number 16

From jsq  Wed Dec 18 18:28:42 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: P1003 Draft 6 -- Comments, criticisms etc.; V4N11; V4N17
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 18 Dec 85 23:28:35 GMT
Draft-9: 2.7

>From seismo!rochester!rocksanne!sunybcs!colonel Mon Dec 16 22:27:37 1985
Date: Mon, 16 Dec 85 14:12:42 EST
From: seismo!rochester!rocksanne!sunybcs!colonel (Col. G. L. Sicherman)
Message-Id: <[e-mail]>
To: ut-sally!std-unix
Subject: Re: P1003 Draft 6 -- Comments, criticisms etc.; V4N11
In-Reply-To: your article <[e-mail]>

> Date: Wed, 11 Dec 85 17:06:10 EST
> From: Arnold Robbins <[e-mail]>
>
> Sect 2.6 Environment Description:
>
>     It is recommended the follwoing variable names....
>
> Should be "It is recommended that the..."
>                              ^^^^

If you're going to hack the gobbledygook, you might as well get it out
of the passive voice: "We recommend that the ..."

Volume-Number: Volume 4, Number 17

From jsq  Wed Dec 18 18:29:23 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: A final comment on P1003 Draft 6; V4N16 (IPC); V4N17
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Arnold Robbins <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 19 Dec 85 00:09:03 GMT
Draft-9: IPC

Date: Tue, 17 Dec 85 13:19:28 EST
From: Arnold Robbins <[e-mail]>

> Date: Thu, 12 Dec 85 13:25:12 EST
> From: Arnold Robbins <[e-mail]>
>
> Just a final note on the P1003 Draft. I am dismayed by the lack of any IPC
> mechanism other than pipes and signals. While the draft explicitly says that
> one should not use signals for interprocess communication, it is well known
> that pipes and signals are not enough for the "real world".
>
> I realize that the System V IPC mechanisms are usually considered
> non-orthogonal and difficult to learn, and BSD sockets don't seem to be
> general enough either.  But something should be done. It is hard to
> both innovate and standardize at the same time, but some sort of IPC
> should be added.
>
> If this is an issue that has been purposely delayed, OK. As long as the
> committee will acknowledge it as an issue, and eventually address it, I
> won't say anything else.
>
> [ You forgot FIFOs.  It's an acknowledged issue, yes.  -mod ]

I don't like to follow up to my own articles, but it occurred to me a day or
two later that maybe Dennis Ritchie and/or ATT might be willing to donate
Ritchie streams to the emerging standard as an IPC mechanims. I don't know a
whole lot about streams, so they may be inappropriate, but from what I do know,
it seems like they might could be used as a foundataion for both IPC and
networking. This is just a suggestion. Comments from people who have actually
used streams would be appreciated.

The moderator makes a good point; FIFOs do provide pipes for non-related
processes, which is a step in the right direction. I still think some other
IPC mechanisms are needed though.

[ Personally, I always thought FIFOs were rather lacking in several respects:
I just wanted to point out that they are in the standard, flawed as they are.

Considering that streams will be in some forthcoming iteration of System V,
it seems unlikely that AT&T will make their implemenation public domain.
However, there is probably sufficient published material (BLTJ 1984 and
Portland (Summer 1985) USENIX) for interested parties to do their own
implementations.
-mod ]

Again, I hope my comments have been useful.

[Mail received after 12/19 will get stored until I get a new address, so,
while mail replies are normally appropriate, they are not in this case.]

[ The preceding paragraph was not by the moderator.  This one is.
Apologies for the long (five day) pause in posting things to the
newsgroup.  I only expected to be gone a couple of days, but had
some problem with flights out of Mexico.

I will be gone again from 22-29 December.  I will try to find
someone to be guest moderator during that period.
-mod ]

--
Arnold Robbins
CSNET:    arnold@gatech    ARPA:    [e-mail]
UUCP:    { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold

Real Unix hackers disdain wimpy languages like C and AWK in favor of /bin/sh.

Volume-Number: Volume 4, Number 17

From jsq  Fri Dec 20 11:40:55 1985
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: duplicate, balloting, end of V4; V4N19
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 20 Dec 85 17:40:39 GMT
Draft-9: Trial.Use.balloting

Due to a file permission botch, there were two articles numbered V4N17.
The second, by Arnold Robbins, should have been V4N18.

I'm mailing my ballot today on Draft 6 becoming the P1003 Trial Use document.
In addition to a couple of objections (A.7.2 and A.2.2), I'm including copies
of mod.std.unix Volumes 3 and 4 as comments (Volumes 1 and 2 were previously
given to the committee chair).  Thus this is the last article of Volume 4.

Volume-Number: Volume 4, Number 19