Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.22

Internet Message Format | 1991-03-06 | 373KB

From [e-mail]  Fri Oct 26 15:09:37 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12278; Fri, 26 Oct 90 15:09:37 -0400
Posted-Date: 26 Oct 90 19:08:19 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 22
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 26 Oct 90 19:08:19 GMT
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

This is the first article in Volume 22 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Topic.

The USENET newsgroup comp.std.unix, also known as the mailing list
[e-mail], is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

Other related standards bodies and subjects include but are not limited to
    IEEE 1201 and IEEE 1238,
    ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
    the U.S. and other Technical Advisory Groups (TAGs) to WG15,
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba,
    and the USENIX Standards Watchdog Committee.

Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is John S. Quarterman.

Disclaimer.

Postings 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.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


Postings.

Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:

        DNS address            UUCP source route
Submissions    [e-mail]        uunet!std-unix
Comments    [e-mail]    uunet!std-unix-request

The hostname cs.utexas.edu may be used in place of uunet.uu.net or uunet.
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.

The mailing list is distributed on the Internet, UUCP, and elsewhere.
There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
Please send submissions from those networks to [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

If you have access to USENET, it is better (more efficient, cheaper,
less effort for me to manage) to subscribe to the newsgroup comp.std.unix
than to the mailing list.  Submissions should still go to the above
addresses, although many (perhaps most) USENET hosts will forward
attempts to post directly to the newsgroup to the moderator.

Posted articles may originate from uunet.uu.net, longway.tic.com, tic.com,
cs.utexas.edu, or usenix.org.  There are also occasional guest moderators,
who may post from still other machines.  Guest moderators are announced
in advance by the regular moderator.

Archives.

Archives for comp.std.unix or [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to uunet.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/comp.std.unix/archive
or
        ~ftp/comp.std.unix/volume.22
The previous volume may be retrieved as
        ~ftp/comp.std.unix/volume.21.Z
and so forth for more ancient volumes.

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell.

The output of "cd ~ftp/comp.std.unix; ls -l" is in
        ~ftp/comp.std.unix/list
and the output of "cd ~ftp/comp.std.unix; ls -l *" is in
        ~ftp/comp.std.unix/longlist

For further details, retrieve the file
        ~ftp/comp.std.unix/README


General submission acceptance policy.

Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days.  If you wait
and still don't see anything, try sending again.

I usually post about 90% of all submissions.  However, as moderator,
I retain the right to reject submissions.  If a submission does not
appear relevant to comp.std.unix, it is sent back to the submittor with
a note saying why it is not appropriate.  Usually this is because it
just doesn't fit the topic of the newsgroup, in which case I suggest
another newsgroup.  Sometimes it is because someone else has already
given the same answer to a question, in which case I ask if the
submittor really wants it posted.  Occasionally I suggest editing that
would make an article more appropriate to the newsgroup.

Very occasionally I reject an article outright:  this is almost always
because it contains ad hominem attacks, which are never permitted
in this technical newsgroup.  There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.

Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.

Crosspostings are discouraged.  Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix.  This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.



Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of three types:  headers and trailers; comments; and typographical.

Headers and trailers

Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
    either hosta!hostb!host!user or, preferably, user@domain.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.

The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide.  If it's not of worldwide interest, it doesn't belong in
comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest.  If a submission arrives with a
Distribution:  line, such as na or us, I delete that line.

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.

Also, signatures that are excessively long may be truncated.



Comments

Comments by the moderator are sometimes added to clarify obscure
issues.  These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
appear that are written by the moderator:  these always end with
a signature that includes the words ``moderator, comp.std.unix.''

Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].

Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].

Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.

Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possesive or
``its'' as a contraction of ``it is'' are corrected.

Excess white space is deleted.

Lines longer than 80 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



Common kinds of postings.

There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals.  Here are three of the most common.

Calendar of UNIX-Related Events

Susanne W. Smith <[e-mail]> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <[e-mail]> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The first three are posted to
    comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.

These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS.  Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is
Jeff Haemer <[e-mail]>.  Reports on other committees, such as
X3J11, are also included when available.  These reports are reviewed
for publication by John S. Quarterman acting as publisher for the
USENIX Standards Policy Committee, which consists of Quarterman (chair),
Marshall Kirk McKusick (USENIX President), Alan G. Nemeth (past USENIX
President), and Ellie Young (USENIX Executive Director).  The reports
are published in comp.std.unix/[e-mail] and ;login:
The Newsletter of the USENIX Association.  They are also available
for publication elsewhere.

EUUG/USENIX ISO Monitor Project

The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee.  This observer, Dominic Dunlop <[e-mail]>,
writes a report after each WG15 meeting, of which there are usually
two a year.  These reports are reviewed by John S. Quarterman, USENIX
Standards Liaison, acting as manager of the ISO Monitor Project.  They
are published in the EUUG Newsletter (EUUGN), :login;, and comp.std.unix.
They are also available for publication elsewhere.

John S. Quarterman, moderator, comp.std.unix and [e-mail].

Volume-Number: Volume 22, Number 1

From [e-mail]  Fri Oct 26 23:12:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25532; Fri, 26 Oct 90 23:12:41 -0400
Posted-Date: 24 Oct 90 17:41:44 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Chet Ramey)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA)
X-Submissions: [e-mail]
Date: 24 Oct 90 17:41:44 GMT
To: [e-mail]

Submitted-by: [e-mail] (Chet Ramey)

Arnold Robbins writes:

>Anyway, since we're discussing what is and isn't in the POSIX name space,
>I'd like to put in a plug for the /dev/fd directory.

I agree; it makes things like

    join <(prog1) <(prog2) > joined-output-of-progs-1-and-2

possible.

>There's lot of existing practice on this one; it originated in V8, circa
>1984 or earlier, and PD versions for various, more popular, Unix incarnations
>have been around for some time as well.

Keith Bostic has stated that /dev/fd will be in the next release of BSD;
for all I know, it might already be in 4.3-reno.

Chet
--
Chet Ramey            ``As I recall, Doug was keen on boxing.  But
Network Services Group          when he learned to walk, he took up puttin'
Case Western Reserve University      the boot in the groin.''
[e-mail]

Volume-Number: Volume 22, Number 2

From [e-mail]  Fri Oct 26 23:19:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28210; Fri, 26 Oct 90 23:19:52 -0400
Posted-Date: 24 Oct 90 19:11:32 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Craig Presson)
Newsgroups: comp.std.unix
Subject: Re: File system name space (was Re: Standards Update, IEEE 1003.4: Real-time Extensions)
Keywords: More Info Please
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Reply-To: [e-mail] (Craig Presson)
Organization: Intergraph Corporation, Huntsville
X-Submissions: [e-mail]
Date: 24 Oct 90 19:11:32 GMT
To: [e-mail]

Submitted-by: [e-mail] (Craig Presson)

In article <[e-mail]>, [e-mail]
(Arnold Robbins) writes:
|> Submitted-by: [e-mail] (Arnold Robbins)
|>
|> Anyway, since we're discussing what is and isn't in the POSIX name space,
|> I'd like to put in a plug for the /dev/fd directory.  Opening /dev/fd/7 is
|> equivalent to doing a dup(7); it is a generalization of the "treat '-' as
|> stdin" hack used by cat and awk (and others) and allows at least two shells
|> (ksh and rc [see your nearest V10 manual]) to do interesting things like set
|> up non-linear pipelines.  (At least I think rc does it.  I know ksh does.)
|>
|> There's lot of existing practice on this one; it originated in V8, circa
|> 1984 or earlier, and PD versions for various, more popular, Unix
incarnations
|> have been around for some time as well.
|>
|> (In fact, in V8 - V10, /dev/stdin, /dev/stdout, /dev/stderr, and
/dev/tty are
|> links to /dev/fd/0, /dev/fd/1, /dev/fd/2, and /dev/fd/3, respectively.  The
|> last, in particular, is a nice generalization, and eliminates an ugly
special
|> case in the kernel; init just does one more dup.)
|>
|> It's going to be fun watching how /dev/fd will be presented as both for and
|> against the case for "fd-centric" Unix... :-)  Personally, I'm in the
put-it-
|> in-the-filesystem camp.
|> --
|> Arnold Robbins                AudioFAX, Inc. | Laundry increases

Ah, roger, that's a big "ditto" on the virtues of One Big Namespace for
all Permanent Objects. Use subspaces to separate classes (he said
tautologically) *.

But for those of us without access to every Unix manual ever published
(I do have a Version 7 Volume 1), could you fill in a bit more on the
semantics of this hybrid /dev entry? Like what do you get when you open
"/dev/fd/7" and there is no open file using that slot? Does the system
make these entries "invisible" to processes not using them? Do you just
get a classic "It's an error from Unix, you're not supposed to understand"
type return? Or am I Missing Something?


--  ******************************************************
    ** Craig Presson              [e-mail]     **
    ** Intergraph Corporation             MS CR1104     **
    ** Huntsville, AL 35894-0001     [phone]     **
    **                       FAX:    [phone]     **
    ******************************************************
* Those not old enough to remember "Tom Swifties" are encouraged
to forgive my lapse of taste ...

Volume-Number: Volume 22, Number 3

From [e-mail]  Fri Oct 26 23:24:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00235; Fri, 26 Oct 90 23:24:50 -0400
Posted-Date: 24 Oct 90 21:46:11 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (David Dick)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Software Innovations, Inc.
X-Submissions: [e-mail]
Date: 24 Oct 90 21:46:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David Dick)

In <[e-mail]> [e-mail] (HL Rogers) writes:

>Submitted-by: [e-mail]

[discussion about NIST, FIPS, and IEEE standards pace omitted]

>What I fail to understand is IEEE's continuing propensity to violate the
>"prime directive", i.e., their failure to specify common practice.

...

>Attempting to legislate change through IEEE dot n committees may even
>work, but guess what?  Instead of Uncle Sam buying something off the
>shelf for near commodity prices, he has to buy a "special" for inflated
>prices because it had to be especially developed.  Nobody had it, not
>common practice,...  And guess what else?  You, I, Roger Martin, and
>the rest of us collectively make up "Uncle Sam."  It's your money, ace.

But isn't this exactly what has been happening for years in Federal
procurement?  Unfortunately, some of the same forces that encouraged
this in traditional procurement must still be in operation, e.g.,
the need of the procurement bureaucracy to ensure its continued existence.

David Dick
Software Innovations, Inc. [the Software Moving Company(sm)]

Volume-Number: Volume 22, Number 4

From [e-mail]  Fri Oct 26 23:29:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01751; Fri, 26 Oct 90 23:29:31 -0400
Posted-Date: 25 Oct 90 10:48:45 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Alain Williams)
Newsgroups: comp.std.unix
Subject: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Parliament Hill Computers Ltd
X-Submissions: [e-mail]
Date: 25 Oct 90 10:48:45 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Alain Williams)

> Anyway, since we're discussing what is and isn't in the POSIX name space,
> I'd like to put in a plug for the /dev/fd directory.  Opening /dev/fd/7 is
> equivalent to doing a dup(7); it is a generalization of the "treat '-' as
What happens if you do an ``ls -l'' on /dev/fd, do you see the fds which are
open to the ls program or all possible fds, even those which aren't opened ?

> (In fact, in V8 - V10, /dev/stdin, /dev/stdout, /dev/stderr, and /dev/tty are
> links to /dev/fd/0, /dev/fd/1, /dev/fd/2, and /dev/fd/3, respectively.  The
> last, in particular, is a nice generalization, and eliminates an ugly special
> case in the kernel; init just does one more dup.)
I always thought that /dev/tty was a means of getting hold of the tty when
you couldn't be certain that 0,1,2 was connected to it. What you are really
saying is that the UNIX convention of 0,1,2 having ``pre defined uses'' be
extended to `3 always connected to the terminal and used for nothing else'.
It isn't a /dev/fd issue, it is a UNIX convention issue.
The other thing is the /dev/tty is a guaranteed way of getting the terminal
& not something else (that is why the passwd program uses /dev/tty).

Alain Williams

[phone]

phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.

Volume-Number: Volume 22, Number 5

From [e-mail]  Mon Oct 29 15:13:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03242; Mon, 29 Oct 90 15:13:48 -0500
Posted-Date: 29 Oct 90 06:09:08 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Sean Fagan)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
X-Submissions: [e-mail]
Date: 29 Oct 90 06:09:08 GMT
To: [e-mail]

Submitted-by: [e-mail] (Sean Fagan)

In article <[e-mail]> [e-mail] (Alain Williams) writes:
>What happens if you do an ``ls -l'' on /dev/fd, do you see the fds which are
>open to the ls program or all possible fds, even those which aren't opened ?

You get something that looks like

kithrup 10> ls -l /dev/fd
total 0
crw-rw-rw- 5 bin    bin    46,0    Jun 11 15:48 0
crw-rw-rw- 5 bin    bin    46,1    Jun 11 15:48 1
crw-rw-rw- 2 bin    bin    46,2    Jun 11 15:48 2
crw-rw-rw- 1 bin    bin    46,3    Jun 11 15:48 3
crw-rw-rw- 1 bin    bin    46,4    Jun 11 15:48 4
crw-rw-rw- 1 bin    bin    46,5    Jun 11 15:48 5

And so on.  They are normal device drivers; stat'ing them doesn't do
anything strange, just opening them.

(/dev/stdin.o, /dev/stdin.s, /dev/stdin.c, /dev/stdin, and /dev/fd/0 are all
linked on my system; similarly with /dev/stdout.  /dev/stderr is linked to
/dev/fd/0, and all the others [through 60 on my system] only have one link.)

--
-----------------+
Sean Eric Fagan  | "Quoth the raven,"
[e-mail]    | "Eat my shorts!"
uunet!sco!seanf  |     -- Lisa and Bart Simpson
[phone]   | Any opinions expressed are my own, not my employers'.

Volume-Number: Volume 22, Number 6

From [e-mail]  Mon Oct 29 15:19:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05099; Mon, 29 Oct 90 15:19:28 -0500
Posted-Date: 29 Oct 90 13:12:45 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Alain Williams)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Parliament Hill Computers Ltd
X-Submissions: [e-mail]
Date: 29 Oct 90 13:12:45 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Alain Williams)

> I agree; it makes things like
>
>     join <(prog1) <(prog2) > joined-output-of-progs-1-and-2
>
> possible.
Such things are possible *now*, you don't need /dev/fd to do it, just an
intelligent shell that doesn't mind making & destroying fifos.

Anyway, the above wouldn't work with a straight /dev/fd as has been talked about
here recently. Why ? The trouble is that if /dev/fd contains files with
names "0", "1", ... "19", the programs prog1 & prog2 would both have a file
/dev/fd/1 as their stdout, join would see another /dev/fd/1.

What is really needed to do what is suggested above is for /proc to contain
an fd directory, thus the command line above would be ``re written'' by the
shell to something like:

    join /proc/1234/fd/1 /proc/1235/fd/1 > joined-output-of-progs-1-and-2
(where 1234 & 1235 are the process ids of prog1 and prog2).

If we adopt the /proc/nnn/fd idea, more questions are raised, for instance what
are the file permissions on /proc/nnn/fd ?

Let me remind the original purpose for which /dev/fd was proposed:
provide a mechanism whereby programs could handle `-' to mean stdin/out
as does cat, but without trying.

Alain Williams

[phone]

phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.

Volume-Number: Volume 22, Number 7

From [e-mail]  Mon Oct 29 15:25:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06982; Mon, 29 Oct 90 15:25:04 -0500
Posted-Date: 29 Oct 90 18:26:01 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Keywords: More Info Please
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AudioFAX Inc., Atlanta
X-Submissions: [e-mail]
Date: 29 Oct 90 18:26:01 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

In article <[e-mail]>, [e-mail] (that's me) writes
lots of stuff about the wonders of /dev/fd, including this point:

>|>   Opening /dev/fd/7 is equivalent to doing a dup(7);

In article <[e-mail]> [e-mail] (Craig Presson) writes:
>But for those of us without access to every Unix manual ever published
>(I do have a Version 7 Volume 1), could you fill in a bit more on the
>semantics of this hybrid /dev entry? Like what do you get when you open
>"/dev/fd/7" and there is no open file using that slot? Does the system
>make these entries "invisible" to processes not using them? Do you just
>get a classic "It's an error from Unix, you're not supposed to understand"
>type return? Or am I Missing Something?

What happens when you do a dup(7) and 7 isn't a valid file descriptor?
It returns -1 and errno is set to EBADF.   So, something along those lines
happens if you open /dev/fd/7, and 7 isn't open.

Now, in article <[e-mail]> [e-mail] (Alain Williams) writes:

>What happens if you do an ``ls -l'' on /dev/fd, do you see the fds which are
>open to the ls program or all possible fds, even those which aren't opened ?

Yes; the files in /dev/fd are character device files, with major and minor
device numbers, just like the entries in /dev for all your ttys.  The major
number is for the fd device driver routine, and the minor number indicates
which fd you're trying to open.  It is a different animal than the /proc,
which is mounted on an in-kernel filesystem.

>> (In fact, in V8 - V10, /dev/stdin, /dev/stdout, /dev/stderr, and /dev/tty are
>> links to /dev/fd/0, /dev/fd/1, /dev/fd/2, and /dev/fd/3, respectively.  The
>> last, in particular, is a nice generalization, and eliminates an ugly special
>> case in the kernel; init just does one more dup.)
>
>I always thought that /dev/tty was a means of getting hold of the tty when
>you couldn't be certain that 0,1,2 was connected to it. What you are really
>saying is that the UNIX convention of 0,1,2 having ``pre defined uses'' be
>extended to `3 always connected to the terminal and used for nothing else'.
>It isn't a /dev/fd issue, it is a UNIX convention issue.

Exactly!  One of the major thrusts of recent versions of Research Unix has
been to simplify, and become as minimalist as possible.  By having fd 3
be the tty and /dev/tty a link to /dev/fd/3, the code in the kernel for
doing /dev/tty goes away.

>The other thing is the /dev/tty is a guaranteed way of getting the terminal
>& not something else (that is why the passwd program uses /dev/tty).

In general, unless someone went to the trouble, fd 3 will be attached to the
terminal, so opening /dev/tty is pretty safe.  Nothing's foolproof; it's
entirely possible that a process can get started off with no controlling
terminal if its parent closed all open files and did the appropriate
incantations to set the process group.  You're no worse off than before
when /dev/tty was built into the kernel.
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail] Phone:   [phone] | number of children.
UUCP:      emory!audfax!arnold Fax-box: [phone] |   -- Miriam Robbins

Volume-Number: Volume 22, Number 8

From [e-mail]  Mon Oct 29 19:14:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01721; Mon, 29 Oct 90 19:14:15 -0500
Posted-Date: 29 Oct 90 22:44:27 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 29 Oct 90 22:44:27 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Sean Fagan) writes:
>>What happens if you do an ``ls -l'' on /dev/fd, ...
>You get something that looks like ...

That's the most common implementation.  However, /dev/fd could also be
implemented as a filesystem type of its own, and I'd actually prefer
that.  Then an "ls /dev/fd" would show just the in-use file descriptors.

Volume-Number: Volume 22, Number 9

From [e-mail]  Tue Oct 30 11:06:18 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25358; Tue, 30 Oct 90 11:06:18 -0500
Posted-Date: 30 Oct 90 06:37:16 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
X-Submissions: [e-mail]
Date: 30 Oct 90 06:37:16 GMT
To: [e-mail]

Submitted-by: [e-mail] (John F. Haugh II)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>That's the most common implementation.  However, /dev/fd could also be
>implemented as a filesystem type of its own, and I'd actually prefer
>that.  Then an "ls /dev/fd" would show just the in-use file descriptors.

Which brings up the issue of "whose in-use file descriptors?".
It would work just fine for the application itself, but "ls" would
be useless if you define "in-use" to be the current process' in-use
descriptors.  Gee, how many times do you want to see which file
descriptors "ls" has open.

This works with /proc because processes are system wide, while file
descriptors are per-process.  My fd0 has nothing in common with your
fd0 - so either I distinguish between my fd0 and your fd0 and get
stuck with fondling every user-page in the system, or I just cop out.

A more complex inplementation buys little or nothing in terms of
function at a very high cost in terms of overhead.
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]
"SCCS, the source motel!  Programs check in and never check out!"
        -- Ken Thompson

Volume-Number: Volume 22, Number 10

From [e-mail]  Tue Oct 30 11:55:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17299; Tue, 30 Oct 90 11:55:29 -0500
Posted-Date: 30 Oct 90 15:12:19 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AudioFAX Inc., Atlanta
X-Submissions: [e-mail]
Date: 30 Oct 90 15:12:19 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

In article <[e-mail]> [e-mail] (Alain Williams) writes:
>> I agree; it makes things like
>>
>>     join <(prog1) <(prog2) > joined-output-of-progs-1-and-2
>>
>> possible.
>Such things are possible *now*, you don't need /dev/fd to do it, just an
>intelligent shell that doesn't mind making & destroying fifos.

Yes, up to a point.  What happens though if you do

    nohup join <(prog1) <(prog2) > joined-output-of-progs-1-and-2 &

and then log out?  The temporary fifos will still be around when the
program finally exits and the shell won't be around to clean them up.
A cron job of some sort could maybe do it, but it's still not as clean
as /dev/fd.

>Anyway, the above wouldn't work with a straight /dev/fd as has been talked about
>here recently. Why ? The trouble is that if /dev/fd contains files with
>names "0", "1", ... "19", the programs prog1 & prog2 would both have a file
>/dev/fd/1 as their stdout, join would see another /dev/fd/1.

No.  The programs have their respective file descriptors 1 attached as pipes,
by the shell via dup, to other "files" in /dev/fd.  The join program would see

    join /dev/fd/4 /dev/fd/5

on its command line.  The scheme requires both /dev/fd and knowledge by the
shell to work completely.  Graphically, you have

    prog1[fd1]>------\
              \
             join[fd4][fd5][fd1]--> output
                /
    prog2[fd1]>-----------/

>What is really needed to do what is suggested above is for /proc to contain
>an fd directory, thus the command line above would be ``re written'' by the
>shell to something like:
>
>    join /proc/1234/fd/1 /proc/1235/fd/1 > joined-output-of-progs-1-and-2
>(where 1234 & 1235 are the process ids of prog1 and prog2).
>
>If we adopt the /proc/nnn/fd idea, more questions are raised, for instance what
>are the file permissions on /proc/nnn/fd ?

As explained above, this already happens.  Permissions on /dev/fd/* should be
666 since no process can affect any other's file descriptors.

>Let me remind the original purpose for which /dev/fd was proposed:
>provide a mechanism whereby programs could handle `-' to mean stdin/out
>as does cat, but without trying.

That's exactly what existing implementations do.  Having ported a version of
a /dev/fd driver into NFS based systems, and used KSH with process substitution
turned on, I can say from experience that it works just fine.  It is such
a nice thing to have that I make gawk (gnu awk) recognize file names of that
type internally and "do the right thing" even if the underlying system does
not support /dev/fd.
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail] Phone:   [phone] | number of children.
UUCP:      emory!audfax!arnold Fax-box: [phone] |   -- Miriam Robbins

Volume-Number: Volume 22, Number 11

From [e-mail]  Tue Oct 30 23:51:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05704; Tue, 30 Oct 90 23:51:54 -0500
Posted-Date: 30 Oct 90 09:01:59 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: Re: File system name space (/dev/fd)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
X-Submissions: [e-mail]
Date: 30 Oct 90 09:01:59 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Kristoffer Eriksson)

In article <[e-mail]> [e-mail] (Alain Williams) writes:

>>     join <(prog1) <(prog2) > joined-output-of-progs-1-and-2

>Anyway, the above wouldn't work with a straight /dev/fd as has been talked about
>here recently. Why ? The trouble is that if /dev/fd contains files with
>names "0", "1", ... "19", the programs prog1 & prog2 would both have a file
>/dev/fd/1 as their stdout, join would see another /dev/fd/1.

That's not how you do it. Prog1 and prog2 just output to their standard
outputs, as they always do, and the shell sets up pipes from prog1 and prog2
to join. The /dev/fd names for these pipes, as seen by join, are then passed
as argv[] parameters to join, to make it read them. Prog1 and prog2 never
see them.
--
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: [phone]  !  e-mail: [e-mail]
Fax:   [phone]  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske

Volume-Number: Volume 22, Number 12

From [e-mail]  Tue Oct 30 23:56:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07278; Tue, 30 Oct 90 23:56:14 -0500
Posted-Date: 30 Oct 90 09:12:25 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: /dev/tty implemented as /dev/fd/3
Summary: Differences from the old implementation?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
X-Submissions: [e-mail]
Date: 30 Oct 90 09:12:25 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Kristoffer Eriksson)

[ I don't quite understand why the submittor wants to split this from the
thread of Re: File system name space, but let's give it a try and see what
happens, eh?  -mod ]

In article <[e-mail]> [e-mail] writes:
>In general, unless someone went to the trouble, fd 3 will be attached to the
>terminal, so opening /dev/tty is pretty safe.  Nothing's foolproof; [...]
>You're no worse off than before when /dev/tty was built into the kernel.

If you have a program that closes only fd 3, this implementation will behave
differently from the old /dev/tty device implementation, won't it? You will
not be able to reach the controlling terminal by a guaranteed route, in spite
of the fact that it is still available on other fd-s. Or is the controlling
terminal concept implemented in such a way that closing fd 3 is the same as
disassociating from the controlling terminal (so you won't be bother with
terminal interrupts and such) ?
--
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: [phone]  !  e-mail: [e-mail]
Fax:   [phone]  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske

Volume-Number: Volume 22, Number 13

From [e-mail]  Wed Oct 31 11:15:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21599; Wed, 31 Oct 90 11:15:02 -0500
Posted-Date: 31 Oct 90 01:28:27 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 31 Oct 90 01:28:27 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] writes:
>     nohup join <(prog1) <(prog2) > joined-output-of-progs-1-and-2 &

> and then log out?  The temporary fifos will still be around when the
> program finally exits and the shell won't be around to clean them up.

You'd have to nohup the whole thing in either case because you'll clobber
prog1 and prog2 when you log out. So this is a non-problem.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 22, Number 14

From [e-mail]  Wed Oct 31 20:11:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26922; Wed, 31 Oct 90 20:11:30 -0500
Posted-Date: 31 Oct 90 09:08:00 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: /dev/tty implemented as /dev/fd/3
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 31 Oct 90 09:08:00 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Kristoffer Eriksson) writes:
> [ I don't quite understand why the submittor wants to split this from the
> thread of Re: File system name space, but let's give it a try and see what
> happens, eh?  -mod ]

It is a different issue. There are objective advantages to eliminating
/dev/tty, kernel controlling terminals, and POSIX sessions: the kernel
becomes noticeably smaller, the POSIX standard becomes several pages
thinner and a lot easier to implement, programmers no longer have to
worry about special system calls to manipulate the tty fd, non-orphaned
processes in orphaned process groups are not killed off unnecessarily,
etc.

Neither SunOS 4.1 nor Ultrix 4.0 correctly implements POSIX sessions.
In particular, both systems chop off access to the original /dev/tty
after a process setsid()s and opens a different controlling terminal.
This is clearly contrary to the intent of POSIX, as expressed in
B.7.1.1.4. It can be proven to be a violation of the standard, as this
removal of access is not defined by either implementation. Note that it
happens only with /dev/tty, not with the actual terminal file; so both
systems are also clearly in violation of the ctermid() definition.

The bugs I just described are solely responsible for the failure of my
pty program under SunOS 4.1 and Ultrix 4.0. (I will post a stopgap patch
by Friday.) If ctermid(), controlling terminals, and POSIX sessions were
not mandated by P1003.1, the Sun and DEC programmers wouldn't have
introduced these bugs into their latest operating systems. Isn't it
obvious that the tty system is a fruitful source of bugs? Shouldn't we
make every effort to simplify this area of UNIX?

v9 could easily adopt fd 3 because it is not a commercial operating
system. It will take a lot more care to introduce similar changes into,
e.g., BSD. I propose the following plan of action:

  1. In the next P1003.1 revision, add a feature test macro for cttys.
     Take *every single sentence in the standard* talking about POSIX
     sessions, cttys, or ctermid(), and make it conditional upon the
     system's optional support for cttys.

  2. Also change the definitions of ``foreground process group'' and
     ``background process group'' in case cttys are not supported. In
     BSD, those terms are relative to the tty you're trying to access.
     In POSIX, they are constant; a process is either in the foreground
     or in the background, depending only on its controlling terminal.
     The new definition would be the same as the old BSD definition.

  3. Add a new device, /dev/stdtty. Opening this device is equivalent to
     dup()ing fd 3. Notice the name ``standard tty''; this is to avoid
     confusion with ``controlling tty.'' stdio should support stdtty as
     well, though (unlike stdin/out/err) stdtty may by convention be
     closed.

  4. Change the few necessary programs (e.g., getty) to support the fd 3
     stdtty convention. In fact, my pty program already supports this
     convention, and the pty package includes patches for telnetd to
     support pty. Adding similar support to getty, rlogind, etc. will be
     just as easy.

  5. Add a new device, /dev/ctty, equivalent to the current /dev/tty.

  6. Switch /dev/tty to be /dev/stdtty rather than /dev/ctty. See if
     anyone notices.

  7. Turn off the ctty feature, to remain compliant with POSIX.
     Eliminate controlling ttys, POSIX sessions, and so on from the
     kernel. Preserve the old behavior of ps by having it glance at fd 3
     inside the process u area---it already looks around enough in
     kernel memory.

> In article <[e-mail]> [e-mail] writes:
> >In general, unless someone went to the trouble, fd 3 will be attached to the
> >terminal, so opening /dev/tty is pretty safe.  Nothing's foolproof; [...]
> >You're no worse off than before when /dev/tty was built into the kernel.
> If you have a program that closes only fd 3, this implementation will behave
> differently from the old /dev/tty device implementation, won't it?

Yes, it will. So what?

> You will
> not be able to reach the controlling terminal by a guaranteed route, in spite
> of the fact that it is still available on other fd-s.

Who cares?

There has not been a ``guaranteed route'' to reach the controlling
terminal, ever since BSD introduced TIOCEXCL. Opening /dev/tty and
sending a TIOCNOTTY down it is not reliable, because /dev/tty may not be
openable. That's right: there is *no* guaranteed way to dissociate from
your controlling terminal. close(3) is a better solution.

Where is this glaring need for a process to find its controlling tty?
Why shouldn't it be easy for the user to control, using the same fd
mechanisms as any other redirection? The argument that ``passwd needs to
talk to the user's tty, reliably'' has been moot ever since pseudo-ttys
appeared.

What is wrong with the concept of a standard tty?

> Or is the controlling
> terminal concept implemented in such a way that closing fd 3 is the same as
> disassociating from the controlling terminal (so you won't be bother with
> terminal interrupts and such) ?

Well, there's no logical association between closing fd 3 and changing
your process group. Dissociating from the controlling terminal takes two
system calls: close(3) and setpgrp(0,0). Attaching to a new one means
open()ing it into fd 3, and then setting process groups appropriately.
There's simply no reason that the ``controlling terminal'' of a process
(whatever that is) should affect the kernel's normal process group
handling.

---Dan

Volume-Number: Volume 22, Number 15

From [e-mail]  Thu Nov  1 10:21:18 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27496; Thu, 1 Nov 90 10:21:18 -0500
Posted-Date: 1 Nov 90 02:29:47 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: /dev/tty implemented as /dev/fd/3
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 1 Nov 90 02:29:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>It is a different issue. There are objective advantages to eliminating
>/dev/tty, kernel controlling terminals, and POSIX sessions: the kernel
>becomes noticeably smaller, the POSIX standard becomes several pages
>thinner and a lot easier to implement, programmers no longer have to
>worry about special system calls to manipulate the tty fd, non-orphaned
>processes in orphaned process groups are not killed off unnecessarily,
>etc.

I think the fundamental problem is that P1003 leaned too much in the
direction of "the system as seen by the user" as opposed to the system
as seen by applications.  Therefore, 1003.1 specified support for BSD-
like job control (as an option, but NBS made it mandatory in the FIPS).
But clearly BSD-like job control is a horrible kludge.  In a superior
environment with /proc and a good multiple-process-managing user
interface, better (and definitely cleaner) implementations of "job
control" are easy to accomplish.  It is the single-tty-channel model
that pretty much forced the signal-based design of the BSD approach,
along with the extra kernel support (that never was gotten fully right
in any implementation I've ever seen, although HP/UX may have been
close).

I agree with the sentiment that such kludgery should be phased out of
the system interface standard.

Volume-Number: Volume 22, Number 16

From [e-mail]  Thu Nov  1 10:29:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29376; Thu, 1 Nov 90 10:29:41 -0500
Posted-Date: 31 Oct 90 17:30:16 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: AudioFAX Inc., Atlanta
X-Submissions: [e-mail]
Date: 31 Oct 90 17:30:16 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

>In article <[e-mail]> [e-mail] writes:
>>     nohup join <(prog1) <(prog2) > joined-output-of-progs-1-and-2 &
>
>> and then log out?  The temporary fifos will still be around when the
>> program finally exits and the shell won't be around to clean them up.

In article <[e-mail]> you write:
>Submitted-by: [e-mail] (Peter da Silva)
>You'd have to nohup the whole thing in either case because you'll clobber
>prog1 and prog2 when you log out. So this is a non-problem.

I didn't think about that, but it's still a problem.  Consider:

    nohup join <(nohup prog1) <(nohup prog2) > joined-output &

I admit to the feasibility of using temporary fifos for process substitution.
It is more work than /dev/fd, but doable.  /dev/fd, though, does make the
whole thing much cleaner.  And it still provides things like

    $ ln -s /dev/stdin foo.c
    $ cc foo.c
    main () { printf("hello, world\n");
    ^D
    $ a.out
    hello, world

I'm not on a crusade here or anything --- I simply think /dev/fd is a neat
idea and I'd like to see it become commonplace.  I don't know how much more
there is to say on the subject...
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail] Phone:   [phone] | number of children.
UUCP:      emory!audfax!arnold Fax-box: [phone] |   -- Miriam Robbins

Volume-Number: Volume 22, Number 17

From [e-mail]  Thu Nov  1 10:33:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00723; Thu, 1 Nov 90 10:33:16 -0500
Posted-Date: 31 Oct 90 17:22:38 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: Re: /dev/tty implemented as /dev/fd/3
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AudioFAX Inc., Atlanta
X-Submissions: [e-mail]
Date: 31 Oct 90 17:22:38 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

In article <[e-mail]> [e-mail] (Kristoffer Eriksson) writes:
>If you have a program that closes only fd 3, this implementation will behave
>differently from the old /dev/tty device implementation, won't it? You will
>not be able to reach the controlling terminal by a guaranteed route, in spite
>of the fact that it is still available on other fd-s.

This is correct.  It's mostly irrelevant though; in current Unix systems if
you do the right magic you can't get use /dev/tty even though the terminal is
still available on the currently open file descriptors.  Six of one, a
half-dozen of the other, as they say.

>Or is the controlling
>terminal concept implemented in such a way that closing fd 3 is the same as
>disassociating from the controlling terminal (so you won't be bother with
>terminal interrupts and such) ?

I don't think this is the case.  V10 still has the concept of a "controlling
terminal", but I strongly doubt that the kernel knows it's on fd 3.  However,
the controlling terminal isn't as pervasive a concept in Research Unix as it
is in BSD or System V.  (In BSD, if you disassociate yourself from the
controlling terminal, and then open some random /dev/tty<whatever>, it
automatically becomes your controlling terminal.  In V10 you'd have to
explicitly make that happen.)

Let me make a clarifying statement.  There are two things under discussion.
1) the usefulness of /dev/fd, 2) the usefulness of having /dev/tty be
/dev/fd/3.   Everyone who's actually used /dev/fd feels it's useful, so
we can take point 1) as a given for a nice feature.  Point 2) has its
plusses and minuses, but, IMO, the minuses don't outweigh the plusses.
Also, if it's good enough for Dennis Ritchie, it's probably good enough
for me. :-)
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail] Phone:   [phone] | number of children.
UUCP:      emory!audfax!arnold Fax-box: [phone] |   -- Miriam Robbins

Volume-Number: Volume 22, Number 18

From [e-mail]  Mon Nov  5 22:49:35 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26916; Mon, 5 Nov 90 22:49:35 -0500
Posted-Date: 6 Nov 90 03:49:03 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: USENIX Standards Funding Decisions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: TIC
X-Submissions: [e-mail]
Date: 6 Nov 90 03:49:03 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

The previous USENIX funding for most standards activities expired on
Halloween (see <[e-mail]>).  The WG15 reports were funded as
requested back in September.  The snitch report editor has apparently
made an arrangement for the interim until the next board meeting in
January.  Efforts are being made to produce proposals for funding other
USENIX standards activities.  However, since the USENIX board has
expressed philosophical objection to funding moderation of a newsgroup,
it is very unlikely that there will ever be support from them for
comp.std.unix.

For the moment, I have chosen to continue as moderator while seeking
support from other quarters.  Preliminary thanks to those who are
already looking into it.

If no funding materializes, I simply cannot afford to continue
taking adequate time to moderate the newsgroup properly, and
we will have to consider opening nominations for a volunteer
moderator and voting on it by the usual USENET procedures.

I strongly recommend keeping comp.std.unix moderated, because:
1) The original request for the newsgroup, from IEEE 1003 back
in 1985 (the first article was posted 25 June 1985), made it
clear that most standards participants would only read a
moderated newsgroup.
2) Comparing 1989 (unfunded) to 1990 (funded), the increased signal
to noise ratio and the increased number of interesting postings
(partly attributable also to the snitch reports, themselves due
to funding of editing) supports the original request.
3) See comp.unix.wizards for what is likely to happen to an
unmoderated comp.std.unix.

Meanwhile, there will be a guest moderator, John B. Chambers,
while I am overseas 6-27 November.  Please send submissions
to the usual address, i.e., [e-mail].

John S. Quarterman, moderator, comp.std.unix and [e-mail]
--
John S. Quarterman
Texas Internet Consulting    [e-mail]    tel: [phone]
701 Brazos, Suite 500      uunet!longway!jsq    fax: [phone]
Austin, TX 78701

Volume-Number: Volume 22, Number 19

From [e-mail]  Thu Nov  8 16:36:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00490; Thu, 8 Nov 90 16:36:10 -0500
Posted-Date: 7 Nov 90 21:55:44 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Sean Fagan)
Newsgroups: comp.std.unix
Subject: POSIX and symbolic links
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The Santa Cruz Operation, Inc.
X-Submissions: [e-mail]
Date: 7 Nov 90 21:55:44 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Fagan)

I've been reading the September 1990 draft of 1003.1a (D4), and have a
question about symbolic links.  The draft specifies that an open of a file
"foo" shall fail if opened with O_CREAT and O_EXCL *both* set (which makes
sense).

But what happens if only O_CREAT is set?  To make it interesting, let's
throw in O_TRUNC as well.  That is:

    fd = open ("foo", O_CREAT|O_TRUNC|O_WRONLY, 0666);

Will the system follow the link, truncating whatever foo points to, if it
exists, or creating it otherwise, or will it truncate foo, creating a
regular file called "foo" with mode 0666&~umask?

My initial guess was that it would follow the link.  However, I can think of
cases where you would not want it to do so (someone then prompted, "Well, if
the sticky bit of the symlink is set, then..." 8-)).

Thanks...

--
-----------------+
Sean Eric Fagan  | "*Never* knock on Death's door:  ring the bell and
[e-mail]    |   run away!  Death hates that!"
uunet!sco!seanf  |     -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor")
[phone]   | Any opinions expressed are my own, not my employers'.




From [e-mail]  Tue Nov 13 11:15:49 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA15887; Tue, 13 Nov 90 11:15:49 -0500
Posted-Date: 13 Nov 90 15:30:33 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Cazier)
Newsgroups: comp.std.unix
Subject: POSIX.1 requires shell???
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The MITRE Corp., Bedford, MA
X-Submissions: [e-mail]
Date: 13 Nov 90 15:30:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Cazier)

Does POSIX.1 require that a shell interface capability exist? I know that
POSIX.2 is still being worked, but is it possible that dot 1 does not
require dot 2, but rather simply allows that if a shell is available it
will be according to dot 2?


Volume-Number: Volume 22, Number 21


From [e-mail]  Wed Nov 14 13:27:57 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA14857; Wed, 14 Nov 90 13:27:57 -0500
Posted-Date: 14 Nov 90 08:59:17 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: POSIX.1 requires shell???
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Cupertino
X-Submissions: [e-mail]
Date: 14 Nov 90 08:59:17 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

> Does POSIX.1 require that a shell interface capability exist? I know that
> POSIX.2 is still being worked, but is it possible that dot 1 does not
> require dot 2, but rather simply allows that if a shell is available it
> will be according to dot 2?

POSIX.1 does not require any shell interface capability to exist.  If one
is provided, it does not have to conform to POSIX.2 (unless, of course,
the system claims to conform to POSIX.2).

Dave Decot

Volume-Number: Volume 22, Number 22

From [e-mail]  Thu Nov 15 12:38:19 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA18413; Thu, 15 Nov 90 12:38:19 -0500
Posted-Date: 14 Nov 90 17:52:43 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Quick answers
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 14 Nov 90 17:52:43 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donn Terry)

1) With respect to the question from Sean Fagan about symbolic links.
   All this is (supposedly, anyway) answered in the new version of
   pathname resolution in 2.3.  Net result: it always follows the symlink.
   (The mental model is that instead of an i-number in a directory entry,
   you could have a name which is the body of the symbolic link.)

2) With respect to the question from "Cazier": POSIX.1 is completely silent
   about a shell, except to the extent that it brings in Standard C by
   reference, and Standard C refers to system().  (And the C definition
   of system() doesn't say much!)  POSIX.1 is strictly from the C-language
   (currently) API point of view.

Donn Terry
(Speaking personally and only for myself.)

Volume-Number: Volume 22, Number 23

From [e-mail]  Thu Nov 15 12:49:46 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA23144; Thu, 15 Nov 90 12:49:46 -0500
Posted-Date: 14 Nov 90 13:17:03 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Report on ISO POSIX meeting of October 1990
Summary: Ada bindings cast adrift
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 14 Nov 90 13:17:03 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)



          Report on ISO/IEC JTC1/SC22/WG15 (POSIX)
            Meeting of 23rd - 26th October, 1990
              Orcas Island, Washington, U.S.A.

              Dominic Dunlop -- [e-mail]

                  The Standard Answer Ltd.


                        Introduction

Are you a regular reader?  I hope so, as this report on the
October meeting of Joint Technical Committee 1, Subcommittee
22, Working Group 15, colloquially known as the ISO POSIX
working group, seems to be particularly replete with
buzzwords, acronyms and jargon.  I try to explain these as I
encounter them, but since USENIX and EurOpen (formerly EUUG)
have been sponsoring me to produce these reports for almost
two years now, some of the explanations are buried in
previous editions.  For now, you will just have to bear with
me; I will take time to explain how we arrived at the
current state of affairs in a future column.  This one
concerns itself mainly with where we are headed, and with
the difficulty of actually getting there.

As far as ISO is concerned, POSIX, like Gaul, is divided
into three parts.  Forget all those proliferating IEEE 1003
POSIX working groups (eighteen of them at the last count),
and just think of three standards: IS 9945-1 for a
definition of the services offered by the operating system;
IS 9945-2 describing the shell and tools; and IS 9945-3,
system administration.

The good news is that you can now buy the first edition of
the first of these1.  The bad news is that all three ISO
standards projects are running into scheduling difficulties.
And there is even more bad news if you are an AdaTM fan:  in
order to ease its own difficulties, the ISO POSIX working
group has put a serious road-block between your favourite
language and an international standard defining how you may
use it to access POSIX services.  Why did we do this, and
why don't we feel bad about it?  Read on...



__________

 1. From the IEEE, which has agreed to print the world's
    first combined IEEE/ANSI/ISO standard -- on ISO standard
    A4 paper.  Ask for IEEE Std. 1003.1:1990.  It will cost
    you $52.50 if you are an IEEE member, $75.00 otherwise.
    Add $5.00 for surface mail to Europe.  In the U.S.A.,
    call (800) 678-IEEE; elsewhere, [phone].  IEEE
    accepts "major credit cards".












                           - 2 -



              9945-3_--_System_Administration

As you are probably aware, the IEEE P1003.7 working group on
system administration has decided that current UNIX
administrative tools and practices are sufficiently
obsolete, inadequate and diverse that they are not worth
standardizing.  Instead, the group has elected to define a
new, object-based administration scheme which views a system
as a collection of objects to be administered, and a network
of systems simply as a larger collection of such objects.

Although this approach grafts neatly on to the network
administration work which has been going on in the Internet
and Open Systems Interconnection (OSI) communities, it will
be a while before it produces any results.  As we shall see
in connection with 9945-2, when ISO delegates responsibility
for the development of a standard to another body, as it has
done with the POSIX standards, it likes the documents to be
in a relatively stable state before they are submitted for
use as ISO Working Documents (WDs).  1003.7 thinks that it
will have something suitable for ISO to start work on by
1992.

Unfortunately, ISO rules state that, unless a project has
resulted in a WD within three years of authorization, the
authorization stands in danger of automatic withdrawal.  The
only way out is for a national standards organization
participating in the development of the standard to call for
a vote on project continuation before the time limit
expires.  The time limit for the production of a draft for
9945-3 has almost been reached, with no prospect of the
deadline being met.

It seems inevitable that the twenty-four countries
participating in the ISO POSIX project will be formally
balloted as to whether they think that the authorization to
develop a system administration standard should stand,
despite the missed deadline.  This is not a particularly big
deal: an examination of ISO's information technology
standardization work reveals that around twenty percent of
projects miss one deadline or another.  (OSI standards have
a particularly poor track record.)

Nevertheless, it is embarrassing when the managerial finger
is pointed at one's own project.  Already, the special
pleading has started; the SC22 Advisory Group, which makes
recommendations on policy issues to the ISO programming
languages subcommittee, has suggested that "in general
standards developed within SC22 are larger and more complex
than most others, and the time limits given in JTC1
directives2...  will therefore often be too short."[1].











                           - 3 -



This may be true -- although work elsewhere in ISO suggests
that SC22 has no monopoly on large projects.  However, it
seems to me that the time limits given by the directives
cannot reasonably be relaxed:  if no visible progress has
been made on a project after three years, those involved had
better be given an opportunity to ask themselves why, and to
consider whether they wish to continue giving their support.
I am sure that, if it comes to a vote, the result will
favour the continuation of the system administration
project.  Just don't hold your breath waiting for the final
standard.

                 9945-2_--_Shell_and_Tools

The shell and tools standard is not crowding a deadline as
closely as is system administration, but is not clear of
trouble either.  At least we have a committee draft (CD --
one step beyond a WD), corresponding to draft 9 of 1003.2,
but have failed to move it forward to the next stage, a
Draft International Standard (DIS).  According to the
directives, we have four years in which to do this before
serious questions get asked, and the ISO directorate makes a
decision about project termination.  Although our progress
to date has not been rapid, we have some time in hand.

Our first attempt to register the 1003.2 draft as a DIS
failed.  (See my report on WG15's Paris meeting[2].)  The
problem was that, while the technical content of a DIS is
supposed to be essentially the same as that which will
appear in the recently International Standard (IS), we all
knew that the content of 1003.2 was still undergoing rapid
and sometimes radical change.  There was no way that draft 9
could have been accepted as a DIS.  (The U.S. National
Institute for Standards and Technology (NIST) ultimately
decided not to base a Federal Information Processing
Standard (FIPS) on draft 9 for similar reasons.)

Draft 11 (or later) of 1003.2 will be passed to ISO in
January, 1991 (or later), in the hope that it can be
registered as a revised CD, and will stand more chance of
clearing the the remaining hurdles which separate it from IS
status.  Until this happens, we have a situation described


__________

 2. The rule book which guides our every move is The JTC1
    Directives.  It is surprisingly readable, and very clear
    on general principles and procedures, but seems to be
    intentionally vague on many details.












                           - 4 -



by one normally restrained working group member as a "pure
disaster".  We are about to suggest that draft 6 of 1003.2A,
the User Portability Extension, due early in 1991, is
registered as a proposed draft amendment (PDAM) to 9945-2,
without having a stable document to amend3!

In this situation, somebody may ask us why we don't just
roll the amendment into the next, hopefully more stable,
version of the CD.  The practical answer to the question is
that the IEEE is treating 1003.2 and 1003.2A as two separate
documents, and we would prefer to do the same.  How much
weight such an argument might carry with the ISO secretariat
is another question...

            9945-1_--_Operating_System_Interface

Now that 9945-1:1990 operating system interface definition
is an international standard, international standards work
on POSIX has reached the end of its beginning.  What do we
do next?  The problem is that we are spoiled for choice.  An
embarrassing number of the 1003 projects represent
extensions to, or restatements of, the services described in
9945-1:

1003.1A:    A 1003.1 extension draft, covering tweaks such
           as symbolic links, will be ready for us early in
           1991.  We shall probably vote to register it at
           our next meeting.

1003.1LI:  (Provisional name.)  This is the language-
           independent specification of the services defined
           by the current 1003.1 standard in terms of their
           C language interface.  It may be ready in late
           1991, provided that enough IEEE volunteers can be
           found to work on it.

1003.1C:   (Provisional name.)  Building on the definition
           provided by 1003.1LI, these C bindings will
           correspond exactly to the C interface defined by
           the current 1003.1.  Again, a draft may be ready
           late in 1991.




__________

 3. The UPE to 1003.2 describes interactive utilities for
    program development, supplementing 1003.2's description
    of the non-interactive tools used in shell scripts.












                           - 5 -



1003.2:    The shell and tools standard defines C language
           interfaces to regular expression handling,
           filename expansion, argument string parsing and
           more.  Arguably, these belong in 9945-1.  They
           are also candidates for language-independent
           specification.

1003.4:    We have requested that the current draft of
           1003.44, real-time extensions to the portable
           operating system interface, is registered as a
           PDAM to 9945-1.  The first international POSIX
           standard has only just hit the streets, and
           already we are trying to amend it!

1003.4A:   The 1003.4 working group considers that draft 5
           of its threads (lightweight process) standard
           will be ready for submission to ISO at the same
           time as 1003.4.  As yet, we have made no decision
           to accept it.

1003.4B:   This is simply a language-independent
           specification for the services described by
           1003.4 in terms of their binding to the C
           language.  The IEEE working group does not know
           when it will be ready, and we don't yet know when
           we shall be ready to accept it.  The two issues
           are connected: if we say we want work on it to be
           accelerated, it is likely to be ready more
           quickly.

1003.5:    The Ada description of the portable operating
           systems interface is well on its way to becoming
           an ANSI/IEEE standard.  Expect to see it in 1992.
           Sadly, for reasons explored below, 1003.5 is
           unsuitable as a basis for an ISO standard.

1003.6:    The security extension to the operating system
           interface will be ready for us to have a look at
           in January of 1991, although it will be a while
           before it is mature enough for PDAM registration.



__________

 4. That is, the draft current at the time that the ISO
    secretariat requests ANSI to provide a document for
    circulation to SC22 and WG15 as a prelude to calling a
    vote on registration.  This will be draft 10, or, more
    probably, draft 11.












                           - 6 -



1003.8:    Transparent file access, that is, transparent
           access by a process hosted on one system to files
           held by another, is making rapid progress after
           narrowing down its goals until it identified an
           achievable target.  The IEEE working group
           expects to have a document suitable for ISO
           review by mid-1991.

1003.9:    The FORTRAN5 bindings to the operating system
           interface definition are written in a manner
           which is more to ISO's taste than the Ada
           description of the same services, and will be
           ready for ISO review in late 1990.  However, we
           have elected not bring it forward to
           international standards status in the near
           future.  Again, our reasons are explored below.

1003.16:   This recently-authorised IEEE project aims to
           produce C language bindings to some future
           language-independent specification of the POSIX
           operating system interface.  Like Ada and
           FORTRAN, it is tied up with the whole issue of
           language independence.

I wrote last time about the background to the language
independence debate[2].  Further discussion and a useful
bibliography can be found in [3].  ISO strongly favours
language-independent service specifications, but very few
people in the U.S. are interested in writing them.  ISO has
delegated development responsibility for POSIX to ANSI,
which in turn has passed the buck to the IEEE -- an
organization which ISO cannot officially talk to or aid.  As
a result, IEEE is saddled with a problem which it is ill-
equipped to solve.

At our Paris meeting, we signalled our disappointment with
the IEEE's progress towards a language-independent
specification for POSIX by refusing to register drafts of
1003.4, .5 and .9.  The list above shows that we have
relented on 1003.4, but have left .5 and .9 out in the cold.




__________

 5. Obscure style note: one is supposed to refer to the
    proposed 1990 version of the language as Fortran; to
    older versions as FORTRAN.  1003.9 is a binding to
    FORTRAN 77.












                           - 7 -



The difference between this meeting and the last is that
they are now definitively out in the cold, and will not be
let into the ISO process until we are very close to having a
language-independent version of IS 9945-1 for them to bind
to.  Here, with a few interpolations in square brackets, is
the resolution that says why:

     Language-Independent Specifications:

     Whereas, SC22 AG [the advisory group mentioned above in
     connection with 9945-2] has recommended that the
     production of language-independent specifications and
     language bindings for POSIX be carried out in such a
     way that it does not delay the standardization of the C
     language bindings[1] [Thank you.  That's just what most
     of us wanted to hear.]; and

     The production of a language-independent specification
     corresponding to IS 9945-1:1990 and subsequent C
     language-based amendments, together with a C language
     binding to that language-independent specification, is
     required by the Division of Work Item JTC 1.22.21 [A
     Division of Work Item is an ISO mechanism for splitting
     an authorised project into several sub-projects]; and

     The production of further language bindings to the
     language-independent specification corresponding to
     9945-1:1990 as subsequently amended is ultimately
     desirable; and

     WG15 considers that "thin" language bindings (which
     must be read in conjunction with a service definition)
     are suitable candidates for standardization, but
     "thick" bindings (those which incorporate a service
     definition duplicating and possibly conflicting with
     the service definition provided by another standard)
     are not [The terms "thin" and "thick" derive from the
     number of pages in the document in question.  1003.5 is
     a "thick" binding, so we do not like it much; 1003.9 is
     a "thin" binding, but to the C language specifications
     of the current 1003.1];

     Therefore, JTC1/SC22/WG15 requests the U.S. member body
     [ANSI, which in turn gets the IEEE to do the work] to
     provide a schedule for the delivery to WG15 and SC22 of
     9945-1-related documents which is subject to the
     following constraints (listed in order of precedence,
     highest first):

       1.  The incorporation or development of language
           independence features shall not be on the











                           - 8 -



           critical path(s) for the production of C
           language-based documents;

       2.  The ultimate goal is the production of an
           extended [extended, that is, by 1003.4, 1003.6,
           1003,8...], language-independent 9945-1 and
           accompanying "thin" binding to the C language at
           the earliest possible date;

       3.  Every attempt shall be made to observe JTC1/ISO
           rules on the bringing forward of amendments etc.,
           with the need to seek waivers being highlighted
           if this appears necessary in order to satisfy the
           constraints above;

       4.  Language bindings, other than those for the C
           language, shall not be brought forward to WG15 or
           SC22 for any purpose other than review and
           comment before the language-independent 9945-1
           has been registered as a DIS; and

       5.  Where possible in the light of other constraints,
           C language-based documents shall include a
           informative annex setting out a language-
           independent definition of the services defined by
           the normative body of the document;

     The schedule shall identify timeframes for at least the
     following document circulation and registration
     milestones:

       1.  "Thick" C bindings for amendments to 9945-1:1990;

       2.  Language-independent specifications corresponding
           to 9945-1:1990 and subsequent amendments;

       3.  "Thin" C bindings to language-independent
           specifications corresponding to 9945-1:1990 and
           subsequent amendments;

       4.  A combined language-independent 9945-1 and
           accompanying "thin" C binding to the services
           that it defines; and

       5.  "Thin" bindings for further languages to the
           whole of the combined language-independent
           9945-1, or to supersets or subsets of the
           services which it defines.

I hope that your eyes have not glazed over:  public
statements of policy get convoluted and legalistic at this











                           - 9 -



level, but all of this verbiage actually represents a
concise description of the problem and what we see as a
route to its solution6.  For the first time, this tells the
IEEE exactly what type of document that the ISO working
group wants to see, and in which order:

  a.  C-based standards first.

  b.  Language-independent standards with a corresponding
      "thin" C binding second.

  c.  "Thin" (and only thin) bindings to other languages no
      sooner than b).

  d.  Examples of language-independent specifications (as
      opposed to definitive standards for them) any time
      that IEEE can manage to produce them.

  e.  All in accordance with ISO rules on the publication of
      amendments and revisions to standards (we hope).

There was some understandable objection from the U.S. to
"micro-management" -- if we were defining so many goals,
constraints and checkpoints, why didn't we just write the
schedule ourselves?  The answer is that there is still quite
a lot of flexibility allowed:  the IEEE has a dozen or more
documents to bring forward, and it can decide on the
ordering.  And the dates.  We just want to know when those
dates are, and to disallow certain orderings.

The amount of resource that the IEEE can muster to work on
language-independent specifications determines when step b
can occur.  Does anybody want to volunteer to make it sooner
than 1995?

The real victim of our newly-defined policy is Ada.  It is
clear that that there will be an ANSI/IEEE standard for an
Ada definition of the POSIX operating system interface,
probably within two years.  It is now equally clear that,
because it will be a "thick" binding, this standard cannot
move forward to gain international status.  There may
ultimately be a "thin" Ada binding to a future language-
independent 9945-1.  It may or, more likely, may not define
an interface identical to that defined by 1003.9.  We could
face the unpalatable prospect of an ISO standard which


__________

 6. Although I could be biased: I drafted the resolution.












                           - 10 -



differs from the corresponding ANSI standard.

Why don't we feel too bad about this?  Well, it seems that
the main requirement for an Ada POSIX standard comes from
within the U.S.  1003.5 will fill this need, and we should
not seek to delay it.  The need for an international
standard in this area is less clear, but we have now given
clear guidelines on the form that it should take, just as
soon as anybody wants to develop it.

That said, it is clear that we still have much to learn
about...

                       Co-ordination

One aim of the IEEE and ISO POSIX projects is that the
international standards that result should be identical to
the corresponding U.S. standards.  Another is that ISO
publication should not lag behind IEEE publication by too
long.  IS 9945-1 is a benchmark in both cases: by dint of
the IEEE agreeing to print for both organizations, content
is identical, and publication is simultaneous.  This will be
a hard act to follow, not least because there are thousands
of pages of IEEE drafts in the pipeline, all of which must
undergo international review before they can even start
going through the three-stage ISO mill which grinds
documents into international standards.

It has been the policy of the IEEE not to submit documents
to ISO until they reach their first IEEE ballots -- that is,
until they are reasonably mature and complete.  In view of
our rejection of 1003.2 draft 9 because we did not consider
it mature enough, this seems like a prudent approach.  The
trouble is that by the time the IEEE considers a document
mature, it is also likely to be difficult to change in any
significant manner.  If we had earlier visibility into the
subject matter and approach of the IEEE's work, we could
comment on its future acceptability to ISO.  For example, we
could have suggested that 1003.5 pursued a "thin", rather
than a "thick" binding.

To try and get out of the hole that we have dug for
ourselves, we have requested "early visibility" of IEEE
draft standards.  Seeing standards when they are young and
small will also aid international understanding of the
larger, more mature versions when they appear.
















                           - 11 -



                           OSCRL

The POSIX project bears a growing similarity to an ancient
yet still inhabited castle: some parts are old and
crumbling; others require constant repair if they are to
remain habitable; and, all the time, new walls, doors and
towers are being added.  1003.7 even seems to be demolishing
a few unsightly outbuildings.  Co-ordination should ensure
that nobody builds a wall where someone else wants a door.
Or a whole new tower when all that was needed was a new
entrance to an existing one, as happened in the case of
1003.5.

No castle is complete without a ghost, and POSIX has one:
OSCRL -- Operating System Command and Report Language.
Started in the early eighties, it was (to simplify to an
almost indictable extent) an attempt to define a common Job
Control Language for the large computers of the day.  It
found a home in SC21, which looks after OSI, just before it
became apparent that UNIX was going to become the "open"
operating system of choice.  Ahead of its time, the OSCRL
project attracted a small but enthusiastic following, but,
as the years went by, work tailed off.  It was all but non-
existent by the time the ISO POSIX project was set up.
However, it is ISO policy when starting new projects to
examine any related work which it may have undertaken, and
the search turned up OSCRL as covering topics to be
addressed by 9945-2 and 9945-3.

SC21 welcomed the chance to pass the project to another
group, and we reluctantly agreed to take it over.  Then the
ISO central secretariat lost all the paperwork.  (It is a
fact of life that all bureaucracies lose paperwork.)  We had
an excuse to prolong OSCRL's spell among the undead,
provided that we could put up with the periodic howls from
its (few) proponents.

These howls recently resulted in a polite suggestion from
the SC22 AG that we should do something to quiet them.  That
something might be the massaging of the existing material
(if it can be found) in to a Technical Report -- a type of
document which few people ever read, and the production of
which is discouraged by ISO.  But a TR may just be the sort
of headstone that OSCRL lacks.  We will be trying to nail
the coffin lid down at our next meeting, which takes place
in the Netherlands from 14th - 17th May, 1991.
















                           - 12 -




                         REFERENCES



 1. Preliminary Recommendations and Resolutions, ISO/IEEE
    JTC1 SC22 Advisory Group, London, October 1990.

 2. Report on ISO/IEEE JTC1/SC22/WG15 (Paris), Dominic
    Dunlop, comp.std.unix Volume 20, Number 110, USENET, 5
    July, 1990 (also published in ;login:, Volume 15, Number
    5, September/October, 1990) No. 3, Autumn 1990

 3. The Context for Programming Language Independence for
    POSIX, Stephen R Walli, comp.std.unix  Volume 21, Number
    197, USENET, 11th October, 1990












































--
Dominic Dunlop


Volume-Number: Volume 22, Number 24

From [e-mail]  Fri Nov 16 12:52:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25824; Fri, 16 Nov 90 12:52:20 -0500
Posted-Date: 15 Nov 90 18:47:45 GMT
Received: by cs.utexas.edu (5.64/1.83)
From: [e-mail] (Fletcher Kittredge)
Newsgroups: comp.std.unix
Subject: Re: Report on ISO POSIX meeting of October 1990
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Fletcher Kittredge)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
X-Submissions: [e-mail]
Date: 15 Nov 90 18:47:45 GMT
To: [e-mail]

Submitted-by: [e-mail] (Fletcher Kittredge)

How can I get copies of draft versions of the POSIX 1003.x standards?
I am particularly interested in the 1003.4[ab] draft.  I am a member
of the IEEE.

regards,
fletcher




Fletcher E. Kittredge
Senior Engineer
Platforms and Tools Group
BBN Software Products Company
10 Fawcett St.
Cambridge, MA. 02138
617-873-3465
[e-mail]  or  [e-mail]

Volume-Number: Volume 22, Number 25

From [e-mail]  Fri Nov 16 12:53:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26334; Fri, 16 Nov 90 12:53:49 -0500
Posted-Date: 15 Nov 90 19:12:51 GMT
Received: by cs.utexas.edu (5.64/1.83)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX.1 requires shell???
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 15 Nov 90 19:12:51 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Cazier) writes:
>Does POSIX.1 require that a shell interface capability exist?

No.

Volume-Number: Volume 22, Number 26

From [e-mail]  Tue Nov 20 23:52:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24702; Tue, 20 Nov 90 23:52:22 -0500
Posted-Date: 20 Nov 90 15:32:57 GMT
Received: by cs.utexas.edu (5.64/1.83)
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Re: Report on ISO POSIX meeting of October 1990
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Bugoslavian Embassy, St. Paul, MN
X-Submissions: [e-mail]
Date: 20 Nov 90 15:32:57 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane P. McCarron)

In article <[e-mail]> [e-mail] writes:
>Submitted-by: [e-mail] (Dominic Dunlop)
>
>In article <[e-mail]> [e-mail] (Fletcher Kittredge)
>writes:
>> How can I get copies of draft versions of the POSIX 1003.x standards?
>> I am particularly interested in the 1003.4[ab] draft.  I am a member
>> of the IEEE.
>
>The contact for IEEE TCOS mailings is
>
>    Charles Habermann

Actually, the contact for obtaining drafts is Lisa Granoien at the
IEEE Computer Society ([phone]).  NAPS does not distribute
draft standards piecemeal

>Subscribers do not have to be IEEE members.  Overseas subscribers must
>pay an additional $400 for express delivery independent of how many or
>few units that they pay for.  (This has always struck me as a rather
>strange approach -- why not just bump up the cost of each unit if
>express delivery is required?)

Actually, the exact cost of overseas express delivery is debited from
each subscribers "account" as materials are shipped.  The $400 is a
ballpark figure that IEEE uses.

Here is the subscription form, in case anyone needs it.  It is
current:


        IEEE TCOS-Standards Document Distribution Service       6-20-90
            INVOICE and Fee Schedule

Name:    ________________________________  Date:  _______________________

Address:________________________________________________________________

    ________________________________________________________________

    ________________________________________________________________

Phone:    ________________________    E-Mail: ________________________

Master Card/Visa/AmEx #:  _______________________  Expiration: _________
         (circle one)
Signature:    ________________________________________________________

Instructions:    Select the working groups from which you would like to
receive information.  Next select the number of pages of material you would
like to pay for at this time.

Group                            All    Drafts
                              Materials    Only
Status    (notices, status reports, document lists)    ____    n/a

ALL    (You will receive materials for new groups    ____    ____
    automatically as they are created)
1003.0    POSIX Guide                    ____    ____
1003.1    System Interface                ____    ____
1003.2    Shell & Utilities                ____    ____
1003.3    Test Methods                    ____    ____
1003.4    Real Time                    ____    ____
1003.5    Ada Bindings                    ____    ____
1003.6    POSIX Security                    ____    ____
1003.7    System Admin.                    ____    ____
1003.8    Transparent File Access                ____    ____
1003.9    Fortran Bindings                ____    ____
1003.10    Supercomputing                    ____    ____
1003.11    Transaction Processing                ____    ____
1003.12    Protocol Independent Interfaces            ____    ____
1003.ns    Name Space/Directory Services            ____    ____
1003.13    Real Time (assigned to .4)             ____    ____
1003.14 Multiprocessing AEP                ____    ____
1003.15 Batch Services (assigned to .10)        ____    ____
1201.1    Windowing Toolkit API                ____    ____
1201.2    User Interface Driveability            ____    ____
1224    X.400 Gateway API                ____    ____
1237    RPC                        ____    ____
1238    Common OSI API & FTAM API            ____    ____

Number of 500 pages units you wish to pay for:    ____ x US$40    _______
(an average mailing of all materials is over 2000 pages)

International Express Mail fee:            ____ US$400    _______
(regular delivery can take up to 8 weeks)

Annual TCOS-Stds meeting attendance fees may be
prepaid:                    ____ US$400    _______
 (or may be paid quarterly at the meetings)

Total amount due for above services:                _______
          Receipt Requested?  Yes  No


Payment:  BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT.  Payment may
be made by charge card (above), or by check or money order payable to
IEEE 1003.  Please retain a copy of this form for your records.  Send
the materials to:

For Subscriptions Send to:    For inquiries about your current subscription:
TCOS Standards Subscriptions            Charles Habermann
c/o Lisa Granoien                 NAPS International
IEEE Computer Society                117 Mackubin St.  Suite 6
1730 Massachusetts Ave. NW            St. Paul, MN  55102
Washington DC  20036-1903            [phone]
     202-371-0101                [phone] (fax)
                        [e-mail]
                        uunet!bungia.mn.org!cjh

--
Shane P. McCarron                Phone: [phone]
Project Manager                    Internet: [e-mail]

Volume-Number: Volume 22, Number 28

From [e-mail]  Wed Nov 21 00:57:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15929; Wed, 21 Nov 90 00:57:04 -0500
Posted-Date: 19 Nov 90 11:09:57 GMT
Received: by cs.utexas.edu (5.64/1.83)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: Report on ISO POSIX meeting of October 1990
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 19 Nov 90 11:09:57 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail] (Fletcher Kittredge)
writes:
> How can I get copies of draft versions of the POSIX 1003.x standards?
> I am particularly interested in the 1003.4[ab] draft.  I am a member
> of the IEEE.

The contact for IEEE TCOS mailings is

    Charles Habermann
    NAPS International
    117 Mackubin Street, Suite 6
    St. Paul, MN 55102
    U.S.A.
    [phone] (voice)
    [phone] (fax)
    [e-mail]

I suggest that you contact him, and he should send you a form to be
filled out and returned, together with payment, to the IEEE.  The idea
is that you pay in advance for 500 page units of mailing at $30 each.
Subscribers do not have to be IEEE members.  Overseas subscribers must
pay an additional $400 for express delivery independent of how many or
few units that they pay for.  (This has always struck me as a rather
strange approach -- why not just bump up the cost of each unit if
express delivery is required?)

The form allows one to specify the groups (1003.x, 1201,z, 1224, 1238)
in which one is interested, and whether one wants to receive all
paperwork or just draft standards.

I am not aware of any way in which individual drafts can be obtained.
I suspect that that's what Fletcher really wants.
--
Dominic Dunlop


Volume-Number: Volume 22, Number 27


From [e-mail]  Wed Nov 28 17:21:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08807; Wed, 28 Nov 90 17:21:52 -0500
Posted-Date: 28 Nov 90 17:37:25 GMT
Received: by cs.utexas.edu (5.64/1.87)
From: [e-mail] (Keith Sklower)
Newsgroups: comp.std.unix
Subject: P1003.12 solicits comments
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 28 Nov 90 17:37:25 GMT
To: [e-mail]

Submitted-by: [e-mail] (Keith Sklower)

The POSIX process-to-process communications working group (P1003.12)
would like to solicit outside comment.

The committee wishes to publish an interface at the level of exposed
detail exhibited by both sockets and XTI.  Previously, the committee
had been of the opinion that although both sets of existing practice
were relatively similar, each had technical flaws.  Furthermore,
each had a user community unwilling to give theirs up and adopt
the other.

The working solution the commitee had been pursuing was to combine
the the best features of the two interfaces, changing the names and
semantics of the primitives, so that some amount of re-coding would
be necessary.  The committee was using as its model the level of
modification done to the job control and termios facilities of P1003.1

There has recently been vociferous opposition to this plan, arguing
that vendors would have to support THREE interfaces (sockets, XTI
and POSIX) and it would be better to have the P1003.12 committee
issue IEEE standard versions of the existing two, with possible
backwards compatible extensions and improvements.

We invite you to submit your reactions to [e-mail]
for consideration by the committee.  It would be helpful to some of us
if you would say something about your background or experience with
either of XTI or sockets.

Volume-Number: Volume 22, Number 19

From [e-mail]  Fri Dec 14 09:08:35 1990
Received: from CS.UTEXAS.EDU by uunet.UU.NET (5.61/1.14) with SMTP
    id AA04163; Fri, 14 Dec 90 09:08:35 -0500
Posted-Date: 14 Dec 90 03:12:18 GMT
Received: by cs.utexas.edu (5.64/1.90)
From: [e-mail] (Insufficient Dada)
Newsgroups: comp.std.unix
Subject: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 14 Dec 90 03:12:18 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Insufficient Dada)

POSIX apparently specifies that the TIOCGPGRP ioctl is disabled if
called on a terminal other than the controlling terminal of the
calling process, apparently for security reasons. This behavior breaks
the subshell handling of GNU Emacs, and apparently interferes with the
operation of the XView terminal emulator as well.  GNU Emacs uses ptys
to communicate with shell subprocesses, and attempts to send signals
to the foreground process in a subshell by finding the process group
associated with the (master side of the) pty.

With TIOCGPGRP disabled, there seems not to be any way to send signals
to a process running in an inferior shell other than figuring out the
appropriate control character to send through termio to cause the
signal to be sent.

Does POSIX have an alternate mechanism for this?  If not, could
someone elaborate on the security problems with allowing a process to
find the pgrp of an arbitrary tty?  How about allowing a process to
find the pgrp of the slave side of a pty when it owns the master side?

    Nick

Nick Thompson        [e-mail]        ...!uunet!sgi!nix

Volume-Number: Volume 22, Number 30

From [e-mail]  Sun Dec 16 06:49:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25539; Sun, 16 Dec 90 06:49:48 -0500
Posted-Date: 14 Dec 90 19:52:18 GMT
Received: by cs.utexas.edu (5.64/1.90)
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Kithrup Enterprises, Ltd.
X-Submissions: [e-mail]
Date: 14 Dec 90 19:52:18 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Insufficient Dada) writes:
>This behavior breaks
>the subshell handling of GNU Emacs, and apparently interferes with the
>operation of the XView terminal emulator as well.

First of all, emacs needs to do a setsid() in the sub-process; this makes
the pty it's controlling terminal (at least, this is how it works under
SCO's unix).

Second of all, because of the problem with tcgetpgrp() on another process'
pty, I added (for my own use) a new ioctl to the pty driver, called TIOCSIG
(as in, ioctl(fd, TIOCSIG, signo)), which sends an arbitray signal to the
process group on fd.  (Since I did it only for emacs, I didn't put in any
checks for security, although I plan on doing so eventually.)

I got this idea from a discussion with people at Berkeley.

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 31

From [e-mail]  Tue Dec 18 18:47:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27070; Tue, 18 Dec 90 18:47:11 -0500
Posted-Date: 17 Dec 90 20:37:52 GMT
Received: by cs.utexas.edu (5.64/1.90)
From: [e-mail] (Bob Lenk)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 17 Dec 90 20:37:52 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Bob Lenk)

In article <[e-mail]> [e-mail] (Insufficient Dada) writes:

> With TIOCGPGRP disabled, there seems not to be any way to send signals
> to a process running in an inferior shell other than figuring out the
> appropriate control character to send through termio to cause the
> signal to be sent.
>
> Does POSIX have an alternate mechanism for this?

No.

>                                                   If not, could
> someone elaborate on the security problems with allowing a process to
> find the pgrp of an arbitrary tty?

I have not identified one after asking various people involved in
writing that portion of the standard.

>                                     How about allowing a process to
> find the pgrp of the slave side of a pty when it owns the master side?

There is nothing in any POSIX standard that specifies the master side
of a pty.  Thus such a feature would have no problems with respect to
the standard.

In article  <[e-mail]> [e-mail] (Sean Eric Fagan) writes:

> Second of all, because of the problem with tcgetpgrp() on another process'
> pty, I added (for my own use) a new ioctl to the pty driver, called TIOCSIG
> (as in, ioctl(fd, TIOCSIG, signo)), which sends an arbitray signal to the
> process group on fd.  (Since I did it only for emacs, I didn't put in any
> checks for security, although I plan on doing so eventually.)

Again, pty master features are not covered by POSIX.  There are some
tradeoffs between these two approaches.  Supplying the process group ID
through the pty master means that if the process running controlling the
master side is no privileged (typically root), it will be unable to
send signals to processes that have changed user IDs (eg. su).  However,
the ioctl to send a signal requires appropriate security checks in a
production implementation.  There are questions as to what these need to
be; I suggest that the process should be able to send any tty signals
but no others, since any process/user on the slave slide accepted (at
least implicitly) the possibility of receiving these when affiliating
with a (pseudo) terminal.

        Bob Lenk
        [e-mail]
        {uunet,hplabs}!fc.hp.com!rml

Volume-Number: Volume 22, Number 32

From [e-mail]  Tue Dec 18 18:49:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27581; Tue, 18 Dec 90 18:49:22 -0500
Posted-Date: 17 Dec 90 22:04:40 GMT
Received: by cs.utexas.edu (5.64/1.90)
From: ccicpg![e-mail] (Sharad Srivastava)
Newsgroups: comp.std.unix
Subject: POSIX interface for Direct I/O.
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: ICL North America, Irvine CA
X-Submissions: [e-mail]
Date: 17 Dec 90 22:04:40 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sharad Srivastava)

I am trying to get the POSIX standard on Direct I/O.

By Direct I/O, I mean the ability to read/write data directly from/to
a regular file into/from user address space without going through kernel
space.

Specifically, I need the ioctl command and argument bits.

Can anyone help ?

                        - Thanx
                          Sharad Srivastava

Volume-Number: Volume 22, Number 33

From [e-mail]  Fri Dec 21 15:48:27 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA27464; Fri, 21 Dec 90 15:48:27 -0500
Posted-Date: 19 Dec 90 17:03:47 GMT
Received: by cs.utexas.edu (5.64/1.91)
From: [e-mail] (Mark Conrad)
Newsgroups: comp.std.unix
Subject: ONLINE POSIX SPEC's
Keywords: POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 19 Dec 90 17:03:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Mark Conrad)

Hello,

    I would like to be able to get a copy of the POSIX spec's,
    especially the real-time drafts over the net.  Does anyone
    out there have these online and available to the net?

    Please mail & post, others would probably like to get
    access to these as well.

    Thank you!

            mail: [e-mail]




Volume-Number: Volume 22, Number 34

From [e-mail]  Fri Dec 21 16:03:17 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA00467; Fri, 21 Dec 90 16:03:17 -0500
Posted-Date: 20 Dec 90 21:13:25 GMT
Received: by cs.utexas.edu (5.64/1.91)
From: [e-mail] (Donald Lewine)
Newsgroups: comp.std.unix
Subject: qfork()
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 20 Dec 90 21:13:25 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

[[I hope that this has not been covered in detail on comp.std.unix.
  Delivery of the newsgroup has been uneven for the last few weeks.]]

[It's not been so much delivery as posting, due to lessened attention
on my part because of lack of funding, and also because of no snitch
reports.  -mod]

Draft 5 of POSIX.1a defines qfork() by saying:
"The qfork() function shall be identical to the fork() function with
 the following exception: behavior is undefined if the child process
 executes any code between the return from qfork() and the succeeding
 call to one of the exec functions or _exit()."

This seems to be a very harsh restriction.  The following code seems
like it would be undefined:
    status = qfork();
    if (status == 0) execve(...);

I would propose replacing the phrase: "executes any code" with "calls
any function defined in this standard or the C standard {8}"  I think
that does what you mean.

--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]

Volume-Number: Volume 22, Number 35

From [e-mail]  Fri Dec 21 16:57:44 1990
Received: from CS.UTEXAS.EDU by uunet.uu.net (5.61/1.14) with SMTP
    id AA12662; Fri, 21 Dec 90 16:57:44 -0500
Posted-Date: 21 Dec 90 20:25:01 GMT
Received: by cs.utexas.edu (5.64/1.91)
From: [e-mail] (Lars Henrik Mathiesen)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Institute of Computer Science, U of Copenhagen
X-Submissions: [e-mail]
Date: 21 Dec 90 20:25:01 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Lars Henrik Mathiesen)

[e-mail] (Bob Lenk) writes:
>Again, pty master features are not covered by POSIX.  There are some
>tradeoffs between these two approaches.  Supplying the process group ID
>through the pty master means that if the process running controlling the
>master side is no privileged (typically root), it will be unable to
>send signals to processes that have changed user IDs (eg. su).  However,
>the ioctl to send a signal requires appropriate security checks in a
>production implementation.  There are questions as to what these need to
>be; I suggest that the process should be able to send any tty signals
>but no others, since any process/user on the slave slide accepted (at
>least implicitly) the possibility of receiving these when affiliating
>with a (pseudo) terminal.

We're discussing an ioctl, usable on a master pty to send terminal
signals to processes in the slave side's process group, right?

I'd very much hope that such an ioctl would include checks for the
termio settings of the slave side: A signal should only be allowed if
it would be possible to write a character on the master pty to achieve
the same result. (And then, why not do just that?)

Otherwise, a set-uid process that unsets the ISIG flag might be
subverted with unexpected signals by users running it under a pty.
(Personally, I'd block the signals as well, but I'm not everybody.)

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      [e-mail]

Volume-Number: Volume 22, Number 36

From [e-mail]  Sun Dec 23 13:56:32 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA03660; Sun, 23 Dec 90 13:56:32 -0500
Posted-Date: 22 Dec 90 05:38:33 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Kithrup Enterprises, Ltd.
X-Submissions: [e-mail]
Date: 22 Dec 90 05:38:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Lars Henrik Mathiesen) writes:
>I'd very much hope that such an ioctl would include checks for the
>termio settings of the slave side: A signal should only be allowed if
>it would be possible to write a character on the master pty to achieve
>the same result. (And then, why not do just that?)

Because that won't support existing practice.

Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob."  It is
defined to send a SIGINT to the process group.  Not a control-c, or DEL, or
whatever you have your interrupt character defined as.  Note that emacs
terminates the shell by sending it (I believe) a SIGTERM.  What keyboard
sequence generates that signal?

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 37

From [e-mail]  Wed Dec 26 14:13:39 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA00241; Wed, 26 Dec 90 14:13:39 -0500
Posted-Date: 23 Dec 90 18:32:15 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: think![e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
X-Submissions: [e-mail]
Date: 23 Dec 90 18:32:15 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (Sean Eric Fagan) writes:
>In article <[e-mail]> [e-mail] (Lars Henrik Mathiesen) writes:
>>I'd very much hope that such an ioctl would include checks for the
>>termio settings of the slave side: A signal should only be allowed if
>>it would be possible to write a character on the master pty to achieve
>>the same result. (And then, why not do just that?)

>Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob."  It is
           ^^^^^^
           C-cC-C
>defined to send a SIGINT to the process group.  Not a control-c, or DEL, or
>whatever you have your interrupt character defined as.

One problem I've run into with the current implementation is that it has
trouble when I run a setuid program in the shell buffer.  The Emacs process
can't send signals to the setuid process.  I ended up redefining C-cC-c and
C-cC-z to just stuff ^C and ^Z into the pty.

However, your idea of an ioctl to send a signal to the other side of a pty
(I assume that's what this is about, I missed the beginning of the
discussion) seems like it would be just right.  Normal terminal users
sometimes get stuck because a program disables control characters and then
a bug sends it into an infinite loop.  The problem is the multiplexing of
the keyboard for input to the program and process control.  On the other
hand, when a program is being run through a pty there is no need to disable
signals just because the signal *characters* are disabled.  Ioctls provide
the needed out-of-band mechanism for process control that is not available
on a real terminal.

--
Barry Margolin, Thinking Machines Corp.

[e-mail]
{uunet,harvard}!think!barmar

Volume-Number: Volume 22, Number 38

From [e-mail]  Wed Dec 26 14:23:58 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA01606; Wed, 26 Dec 90 14:23:58 -0500
Posted-Date: 24 Dec 90 16:57:44 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
X-Submissions: [e-mail]
Date: 24 Dec 90 16:57:44 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>"The qfork() function shall be identical to the fork() function with
> the following exception: behavior is undefined if the child process
> executes any code between the return from qfork() and the succeeding
> call to one of the exec functions or _exit()."
>
>This seems to be a very harsh restriction.  The following code seems
>like it would be undefined:
>    status = qfork();
>    if (status == 0) execve(...);
>
>I would propose replacing the phrase: "executes any code" with "calls
>any function defined in this standard or the C standard {8}"  I think
>that does what you mean.

I think that loosens the restriction too much.  The intent of the text, I
believe, is that *doing* anything between qfork() and exec*() results in
undefined behavior. Checking a variable doesn't *do* anything in this sense.
The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
share-memory pseudo-fork or is it a real fork or what?" An application which
takes an action after qfork() and before exec*() that depends upon the
implementation of qfork() being any one of those things is inherently
unportable.

Instead of replacing "executes any code", I think you could just add the
phrase "which modifies memory or calls any function" and maintain the
intent. Examining variables doesn't depend upon the virtual memory
relationship between child and parent, but munging a stack for a function
call might behave differently and hence must be rendered undefined.

Jason Zions

Volume-Number: Volume 22, Number 39

From [e-mail]  Thu Dec 27 12:21:19 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA19339; Thu, 27 Dec 90 12:21:19 -0500
Posted-Date: 26 Dec 90 22:42:07 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Ohio State Computer Science
X-Submissions: [e-mail]
Date: 26 Dec 90 22:42:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

Of course assuming that the parent doesn't care about the return value
of qfork(), then one could manage to conform to the restrictions by:

    if (qfork() == 0) exit(execve(...));

or for the truly sick-at-heart:

    (status = qfork()) ? 1 : exit(execve(...));

(Of course it _could_ be argued that, in the second example, the very
assignment of status = qfork() violates the rules, but I thought the
humor value was high.)

But _I'm_ not writing code like that! <grin>

Terri


Volume-Number: Volume 22, Number 40

From [e-mail]  Thu Dec 27 12:24:15 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA19798; Thu, 27 Dec 90 12:24:15 -0500
Posted-Date: 26 Dec 90 22:54:50 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: think![e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
X-Submissions: [e-mail]
Date: 26 Dec 90 22:54:50 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>Instead of replacing "executes any code", I think you could just add the
>phrase "which modifies memory or calls any function" and maintain the
>intent. Examining variables doesn't depend upon the virtual memory
>relationship between child and parent, but munging a stack for a function
>call might behave differently and hence must be rendered undefined.

Rather than "modifies memory" I suggest it be "modifies any variables" or
something like it that refers to high-level objects created by the C
program.  Just examining a variable may modify memory; on a stack machine,
comparing a variable with zero generally requires pushing the variable onto
the stack, and even on a register machine loading the variable into a
register might force the register's old value to be written to memory.
--
Barry Margolin, Thinking Machines Corp.

[e-mail]
{uunet,harvard}!think!barmar

Volume-Number: Volume 22, Number 41

From [e-mail]  Fri Dec 28 10:49:09 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA21064; Fri, 28 Dec 90 10:49:09 -0500
Posted-Date: 27 Dec 90 18:56:25 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 27 Dec 90 18:56:25 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Donald Lewine) writes:
> I would propose replacing the phrase: "executes any code" with "calls
> any function defined in this standard or the C standard {8}"  I think
> that does what you mean.

How about "executes any code that changes the state of the program". So,
for example:

    static int child;

    child = 0;
    if(qfork() == 0) {
        child = 1;
        exec...;
    }

At this point, unless I'm confused about legal interpretations of "qfork()",
the value of "child" is indeterminate.
--
Peter da Silva.   `-_-'    "Eat hot digital death, mainframe scum!"
[phone].   'U`          -- Attack of the Killer Micros.
[e-mail]

Volume-Number: Volume 22, Number 43

From [e-mail]  Fri Dec 28 20:11:33 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA17414; Fri, 28 Dec 90 20:11:33 -0500
Posted-Date: 28 Dec 90 14:24:10 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: arnor![e-mail]
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IBM T.J. Watson Research Center, Hawthorne, New York
X-Submissions: [e-mail]
Date: 28 Dec 90 14:24:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

It would be useful to know why the function is being proposed.  One
assumes an efficiency improvement, which implies that the specifiers
have an implementation in mind.

Also, it should be remembered that unix systems don't execute C - they
execute machine instructions generated by the C compiler.  So it is
necessary to specify the behavior in machine terms if the compiler
writers are going to comply.  In particular, there is nothing to
prevent the compiler from moving certain computations to the space
between the qfork and the exec!  Does a compiler need to recognize
qfork and exec as special?

Finally - if the intent is to "bundle" fork and exec together,
assuming only that the fork succeeds, would it not be better to
propose fexec* - a set of exec calls which fork first?  Of course,
this makes it absolutely clear that nothing can happen between fork
and exec.  If the combined function is then deemed useless, how can
the qfork/exec idiom be better?
--

Marc Auslander       <[e-mail]>


Volume-Number: Volume 22, Number 44

From [e-mail]  Fri Dec 28 22:16:38 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA00675; Fri, 28 Dec 90 22:16:38 -0500
Posted-Date: 29 Dec 90 02:29:38 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Lars Henrik Mathiesen)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Institute of Computer Science, U of Copenhagen
X-Submissions: [e-mail]
Date: 29 Dec 90 02:29:38 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Lars Henrik Mathiesen)

[e-mail] (Sean Eric Fagan) writes:
>[e-mail] (Lars Henrik Mathiesen) writes:
>>I'd very much hope that such an ioctl would include checks for the
>>termio settings of the slave side: A signal should only be allowed if
>>it would be possible to write a character on the master pty to achieve
>>the same result. (And then, why not do just that?)

>Because that won't support existing practice.

>Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob."  It is
>defined to send a SIGINT to the process group.  Not a control-c, or DEL, or
>whatever you have your interrupt character defined as.  Note that emacs
>terminates the shell by sending it (I believe) a SIGTERM.  What keyboard
>sequence generates that signal?

That is exactly the point: Keyboard generated signals are more
powerful than the kill system call, because uids are not checked.
Under ``existing practice'' you can send SIGINT, SIGQUIT or SIGTSTP to
all processes in the process group of a pseudo-tty, _even_if_ some of
them are set-uid to someone else.

But a set-uid root program can assume that a SIGTERM comes from a
super-user. If a new ioctl allows any signal to be sent without
checking uids, the rules have been changed (not nice). If it checks
uids for all signals, it's less powerful than keyboard signals, and
why bother to learn about it?

By the way, I will hazard a guess: Most, if not all, of the UNIX
variants where the existing practice of Emacs doesn't work will have
SYSV termios ioctls. So instead of putting in ifdefs for two or three
subtly incompatible new TIOCSENDSIGs, we might as well put in the four
lines to get a termios structure and stuff the appropriate character
down the master pty.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      [e-mail]


Volume-Number: Volume 22, Number 45

From [e-mail]  Sat Dec 29 12:42:39 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA05500; Sat, 29 Dec 90 12:42:39 -0500
Posted-Date: 29 Dec 90 04:25:11 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Kithrup Enterprises, Ltd.
X-Submissions: [e-mail]
Date: 29 Dec 90 04:25:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Lars Henrik Mathiesen) writes:
>By the way, I will hazard a guess: Most, if not all, of the UNIX
>variants where the existing practice of Emacs doesn't work will have
>SYSV termios ioctls.

Yep.  All POSIX systems.

>So instead of putting in ifdefs for two or three
>subtly incompatible new TIOCSENDSIGs, we might as well put in the four
>lines to get a termios structure and stuff the appropriate character
>down the master pty.

(shell)
<stuff>
kithrup 341> stty intr ^Y
kithrup 342> <C-cC-c>^?<C-cC-c>^?<C-cC-c>^?<C-cC-c>^?

Gosh.  It doesn't seem to be sending the control-y to the slave side of the
pty!  And, gosh, if it tries to do a TCGETAW, it just hangs!  (Actually, I
think it gets a SIGTTIN.)

Some of this is SCO specific.  But without rewriting the pty driver, *any*
POSIX system with ptys is going to have the same problem (since sco's pty
drivers aren't that different from berkeley's).

According to email I exchanged with someone at CSRG, 4.4 will support the
old method, but as an obsolescent feature.

If the text is so ambiguous that it is implemented differently on every
system, that means that you will need more ifdef's than with just the
TIOCSIG ioctl.

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 46

From [e-mail]  Sat Dec 29 12:45:38 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA05844; Sat, 29 Dec 90 12:45:38 -0500
Posted-Date: 28 Dec 90 20:54:07 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (John F Haugh II)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
X-Submissions: [e-mail]
Date: 28 Dec 90 20:54:07 GMT
To: [e-mail]

Submitted-by: [e-mail] (John F Haugh II)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>How about "executes any code that changes the state of the program". So,
>for example:

executing =any= code changes the state of the program.  that's the whole
problem with this restriction - how much code is too much.

>At this point, unless I'm confused about legal interpretations of "qfork()",
>the value of "child" is indeterminate.

what is probably needed is a "spawn()" function (god, i never thought i'd
advocate such a critter) which can be responsible for understanding the
legalese.  if the only thing you can do after "qfork()" is "exec()", why
not merge the two steps into a single function?  sounds like the only way
to get it right anyhow.
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."

Volume-Number: Volume 22, Number 47

From [e-mail]  Mon Dec 31 16:04:46 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA29285; Mon, 31 Dec 90 16:04:46 -0500
Posted-Date: 30 Dec 90 03:11:23 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 30 Dec 90 03:11:23 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
> what is probably needed is a "spawn()" function (god, i never thought i'd
> advocate such a critter) which can be responsible for understanding the
> legalese.

Wow, this is the same man who ever so politely flamed me for daring to make
such a suggestion. fork can be implemented on a large number of O/Ses, but
it's rather expensive. If the POSIX standard includes something like a
spawn(), that'll sure increase the efficiency of a lot of POSIX software on
systems that have been shoehorned into the model.

Yes, fork() is a cleaner method of creating new processes. Yes, it takes
a fairly complex calling sequence to get spawn() to have anything like
the functionality of fork()...exec(). But I think it'd be worthwhile to
let a little heresy in in exchange for making POSIX more palatable to
folks in poorer environments.

The few cases where spawn() won't fit would usually be better addressed by
something like threads anyway...
--
Peter da Silva.   `-_-'    "Eat hot digital death, mainframe scum!"
[phone].   'U`          -- Attack of the Killer Micros.
[e-mail]

Volume-Number: Volume 22, Number 48

From [e-mail]  Mon Dec 31 16:09:13 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA29615; Mon, 31 Dec 90 16:09:13 -0500
Posted-Date: 30 Dec 90 16:17:40 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: tmsoft![e-mail] (Dave Mason)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tmsoft![e-mail] (Dave Mason)
Organization: TM Software Associates, Toronto
X-Submissions: [e-mail]
Date: 30 Dec 90 16:17:40 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dave Mason)

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
>Submitted-by: [e-mail] (John F Haugh II)
>In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>>How about "executes any code that changes the state of the program". So,
>>for example:
>executing =any= code changes the state of the program.  that's the whole
>problem with this restriction - how much code is too much.

The real requirement is presumably: ``Must not execute any code that
changes MEMORY.'' As both the parent and child have their own register
sets.  Now, expressing that in a high-level way that is portable may
be quite a trick.  (Think of SPARC vs. 386 vs. HP/3000!)

>>At this point, unless I'm confused about legal interpretations of "qfork()",
>>the value of "child" is indeterminate.

Not if it's a register variable.

>what is probably needed is a "spawn()" function (god, i never thought i'd
>advocate such a critter) which can be responsible for understanding the
>legalese.  if the only thing you can do after "qfork()" is "exec()", why
>not merge the two steps into a single function?  sounds like the only way
>to get it right anyhow.

Not really.  Assuming qfork in the parent can make sure there is
nothing on its stack (that it needs to retrieve later) before it
executes the system call instruction, and the child doesn't do
anything except:
  a) make system calls that change its KERNEL state (open files, UID, etc.)
  b) change register variables
qfork can do everything useful that vfork can. (And because there's no
memory being changed by the child that can be inspected by the parent, a
fork implementation of qfork is still legal.)

(Personally I think the whole vfork/qfork/spawn thing is a horrible hack,
but if we're going to be stuck with it, lets at least do it right!)

--
"Don't break it if you can't fix it."                             ../Dave Mason
                                                  <[e-mail]>

Volume-Number: Volume 22, Number 49

From [e-mail]  Mon Dec 31 16:19:17 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA00590; Mon, 31 Dec 90 16:19:17 -0500
Posted-Date: 31 Dec 90 17:39:01 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
X-Submissions: [e-mail]
Date: 31 Dec 90 17:39:01 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>Also, it should be remembered that unix systems don't execute C - they
>execute machine instructions generated by the C compiler.  So it is
>necessary to specify the behavior in machine terms if the compiler
>writers are going to comply.  In particular, there is nothing to
>prevent the compiler from moving certain computations to the space
>between the qfork and the exec!  Does a compiler need to recognize
>qfork and exec as special?

That's specious. Of *course* the compiler needs to recognize system calls as
sync points. It wouldn't do for the compiler to migrate the instructions
which initialize a write() buffer to after the write() call, would it?

>Finally - if the intent is to "bundle" fork and exec together,
>assuming only that the fork succeeds, would it not be better to
>propose fexec* - a set of exec calls which fork first?  Of course,
>this makes it absolutely clear that nothing can happen between fork
>and exec.  If the combined function is then deemed useless, how can
>the qfork/exec idiom be better?

Um, how about "existing practice"? More than that, there's a whole raft of
common extensions revolving around various forms of qfork() that many would
like to see remain as possible extensions.

Jazz

Volume-Number: Volume 22, Number 50

From [e-mail]  Tue Jan  1 14:06:23 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA00214; Tue, 1 Jan 91 14:06:23 -0500
Posted-Date: 1 Jan 91 03:08:13 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (John G Dobnick)
Newsgroups: comp.std.unix
Subject: Finding physical memory size
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 1 Jan 91 03:08:13 GMT
To: [e-mail]

Submitted-by: [e-mail] (John G Dobnick)

This is perhaps a silly question, but since I haven't used this year's
quota of silliness yet... :-)


Our CONVEX system, which claims POSIX compliance, has a system call
that returns "system configuration" information.  If my memory serves
(I'd check, but the books are at work, and the machine is being "PM"ed),
the C-library function 'getsysinfo' retrieves this information.  Among
the items retrieved are

    System type
    Operating system type
    Operating system level (or version number)
    Processor type
    Processor serial number
    number of Processors (But, with multiple processors, shouldn't
                  we also get multiple serial numbers?  Hmmm.)
    Processor option mask (I believe this is an 'extension')
    Memory interleave factor (also an extension, I believe)

One item glaringly missing is the size of physical memory installed.
The writeup for the function claims it returns "system information", not
"CPU information".   In my book, a "system" includes processors AND
memory.

My question, to those of you who know what happened in the
standardization process is threefold:

    a) Was memory size even considered for inclusion in the
       'getsysinfo' (or whatever it's really named) call.

    b) If is was considered, why was it not included.

    c) How does one interrogate the system, in a 'standard' way,
       to determine physical memory size?   (My initial guess is
       that the answer will be "You don't.")

Have a Happy New Year, folks!
--
John G Dobnick  (JGD2)
Computing Services Division @ University of Wisconsin - Milwaukee
INTERNET: [e-mail]             ATTnet: [phone]
UUCP: uunet!uwm!csd4.csd.uwm.edu!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

Volume-Number: Volume 22, Number 51

From [e-mail]  Thu Jan  3 18:20:44 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA26521; Thu, 3 Jan 91 18:20:44 -0500
Posted-Date: 2 Jan 91 01:59:35 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Finding physical memory size
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: U of Toronto Zoology
X-Submissions: [e-mail]
Date: 2 Jan 91 01:59:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] writes:
>Our CONVEX system, which claims POSIX compliance, has a system call
>that returns "system configuration" information...

It is important to understand that "POSIX compliant" invariably means
"POSIX superset", since many significant functions are not part of the
current POSIX standard, 1003.1.  There is no POSIX `getsysinfo' call.
The closest you get is `sysconf()', which can be used to ask about a
few things like the maximum number of open files.  None of the things
you mention are in the list.

>    c) How does one interrogate the system, in a 'standard' way,
>       to determine physical memory size?   (My initial guess is
>       that the answer will be "You don't.")

Correct.  In any case, it is typically not a very useful piece of
information, since there is no simple correlation between the size of
physical memory and how much your program is allowed to use.
--
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| [e-mail]   utzoo!henry

Volume-Number: Volume 22, Number 52

From [e-mail]  Thu Jan  3 19:03:08 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA04252; Thu, 3 Jan 91 19:03:08 -0500
Posted-Date: 2 Jan 91 13:17:31 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (John F Haugh II)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
X-Submissions: [e-mail]
Date: 2 Jan 91 13:17:31 GMT
To: [e-mail]

Submitted-by: [e-mail] (John F Haugh II)

In article <[e-mail]> [e-mail] (Dave Mason) writes:
>The real requirement is presumably: ``Must not execute any code that
>changes MEMORY.'' As both the parent and child have their own register
>sets.  Now, expressing that in a high-level way that is portable may
>be quite a trick.  (Think of SPARC vs. 386 vs. HP/3000!)

Yes, that is the essence of the problem - there are CPUs out there
which have a very small number of CPU registers (perhaps only two
or three) available to the user.  As I recall, the TI 9900 has one
register which points to a location in memory where the rest of the
"registers" exist, and of course older HP CPU's have their own ideas
about where data is stored.
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."

Volume-Number: Volume 22, Number 53

From [e-mail]  Thu Jan  3 19:15:04 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA05872; Thu, 3 Jan 91 19:15:04 -0500
Posted-Date: 2 Jan 91 19:15:16 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Eric Schnoebelen)
Newsgroups: comp.std.unix
Subject: Re: Finding physical memory size
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Convex Computer Corporation, Richardson, Tx.
X-Submissions: [e-mail]
Date: 2 Jan 91 19:15:16 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Eric Schnoebelen)

[e-mail] writes in <[e-mail]>:
-Submitted-by: [e-mail] (John G Dobnick)
-
-Our CONVEX system, which claims POSIX compliance, has a system call
-that returns "system configuration" information.

    First off, getsysinfo(2) is not a POSIX standard routine.  It
is an extension to UNIX that Convex has supported for quite some time.
It is not available in the conforming modes of the C development
environment (compiler and libraries), only the extended/backwards
compatible modes.

    The features of getsysinfo(2) are available as part of the
uname(2) call as well, as an extension to the standard uname
structure.

-One item glaringly missing is the size of physical memory installed.
-The writeup for the function claims it returns "system information", not
-"CPU information".   In my book, a "system" includes processors AND
-memory.
-
-My question, to those of you who know what happened in the
-standardization process is threefold:
-
-    a) Was memory size even considered for inclusion in the
-       'getsysinfo' (or whatever it's really named) call.

    According to the standard, the only things that have to be
returned by uname(2) are the system (implementation) name, the node
(host) name, the release name, the version name, and the hardware type
name. See page 77, section 4.4 of the little green book.

-    c) How does one interrogate the system, in a 'standard' way,
-       to determine physical memory size?   (My initial guess is
-       that the answer will be "You don't.")

    Correct!.  For the Convexen, you  might try contacting the TAC,
and asking them. I seem to remember a little program that determines
just that floating around.

--
Eric Schnoebelen        [e-mail]        [e-mail]
    Biology is the only science in which multiplication means the
            same thing as division.

Volume-Number: Volume 22, Number 54

From [e-mail]  Thu Jan  3 20:15:19 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA17052; Thu, 3 Jan 91 20:15:19 -0500
Posted-Date: 3 Jan 91 09:42:04 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Guido van Rossum)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 3 Jan 91 09:42:04 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Guido van Rossum)

[e-mail] (Peter da Silva) writes:

>Yes, fork() is a cleaner method of creating new processes. Yes, it takes
>a fairly complex calling sequence to get spawn() to have anything like
>the functionality of fork()...exec(). But I think it'd be worthwhile to
>let a little heresy in in exchange for making POSIX more palatable to
>folks in poorer environments.

I know of precedents even in OS'es that support fork(): Amoeba and
Topaz support a variant of what you call spawn().  (Note that the
spawn() functions found in Microsoft C for MS-DOS emulate either just
exec() or fork()+exec()+wait(), which is much less powerful, but
all that MS-DOS can support (last time I looked).)

Amoeba's UNIX emulation supports fork(), but since Amoeba has no virtual
memory (yet), it is fairly expensive.  An alternative function is
provided, "newproc()", which creates a child process running a
different program (and, because it is Amoeba, also running on a
different processor, in the average case) just like fork()+exec() would
do, only much cheaper since the parent's address space never gets
copied.

Amoeba's newproc() lets you change the two perhaps most important
bits of "kernel state" that programs fiddle between fork() and exec():
the set of signals to be ignored and the set of open file descriptors.
The interface lets you specify a bitmask of signals that are to be
ignored in the child (or -1 to inherit the parent's ignored signals)
and an array of file descriptors which provides a mapping between file
descriptors in the parent and in the child (also with an option to
inherit all file descriptors from the parent).

Amoeba's library functions popen() and system() have been changed to
use newproc(), and the shell uses newproc() for most simple program
invocations (environment manipulations and a few other things make it
fall back on fork()).  The performance gain was well worth the hacking.

The newproc() interface could also be implemented on UNIX using
[v]fork() and exec(), although extreme cases of file descriptor
permutations could fail if not enough spare file descriptors were
available.

The Topaz operating system (an Ultrix clone for Firefly multiprocessors
developed at DEC's System Research Centre in Palo Alto) has a similar
but more complete feature in its Modula-2+ (and now Modula-3?) version
of the OS interface, not because Topaz doesn't have virtual memory (it
does), but because the average Modula-2+ binary is several megabytes.

In Topaz, you create a descriptor for the new process, which represents
its relevant kernel state.  The descriptor is initialized to inherit
all state from the parent, and you can call library functions that
modify various parts of the descriptor; this is the equivalent of what
you would do between fork() and exec() in real UNIX.  Finally you make
a system call that presents the descriptor to the kernel for creation.
Yes, it's a bit more tedious, but it has all the required
functionality, unlike (it seems to me) the proposed qfork() with its
not-well-understood restrictions on modifying memory.

--Guido

--
Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Well I'm a plumber.  I can't act."

Volume-Number: Volume 22, Number 55

From [e-mail]  Thu Jan  3 20:21:54 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA18508; Thu, 3 Jan 91 20:21:54 -0500
Posted-Date: 3 Jan 91 15:59:27 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 3 Jan 91 15:59:27 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donn Terry)

To add to the qfork discussion:

1) The purpose of qfork() is similar to that of vfork(), but detailed
   discussions end up showing that there really is nothing that is safe
   to do between the qfork() and the exec() that will not cause problems
   on some architecture or other.  That's the reason for the name change
   from vfork().

2) 1003.5 (Ada) has a entry point "start_process[_search]" which are
   a spawn()-like animal that takes a data structure to tell it what to
   do with file descriptors, user ID's and the like between the fork()
   and exec() that underly it.  (In Ada, fork() + exec() is "unsafe";
   "unsafe" is a dirty word in the Ada community.)

   This might be (observation of fact, not an opinion) a place to start
   for something that does serve the fork(), do a few safe things, exec()
   sequence.

Donn Terry
Speaking only for myself.

Volume-Number: Volume 22, Number 56

From [e-mail]  Thu Jan  3 20:24:41 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA19103; Thu, 3 Jan 91 20:24:41 -0500
Posted-Date: 3 Jan 91 03:56:44 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (John G Dobnick)
Newsgroups: comp.std.unix
Subject: Re: Finding physical memory size
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 3 Jan 91 03:56:44 GMT
To: [e-mail]

Submitted-by: [e-mail] (John G Dobnick)

Following up on my own posting, which I _did_ say was silly, and which
a few kind people have assured me _was_ silly [I knew I shouldn't have
posted that thing New Year's Eve -- too much eggnog around],

>From article <[e-mail]>, by [e-mail] (John G Dobnick):
>
> Our CONVEX system, which claims POSIX compliance, has a system call
> that returns "system configuration" information.  If my memory serves
> (I'd check, but the books are at work, and the machine is being "PM"ed),
> the C-library function 'getsysinfo' retrieves this information.  Among
> the items retrieved are
>
>     *    System type
>     *    Operating system type
>     *    Operating system level (or version number)
>     * Processor type
>     Processor serial number
>     number of Processors
>     Processor option mask
>     Memory interleave factor

(* -- uname fields.  All others are CONVEX extensions)

Memory didn't serve -- what I was thinking of was the "uname()" call,
which does _not_ include any hardware specific information -- only OS
related things.  [It's amazing how eggnog muddles the thought processes]

The hardware specific information another source and is an implementation
specific extension.

Please allow me to rephrase my question as:

    Was consideration given to including some mechanism to retrieve
    hardware configuration information via 'standard' means?

[I'll shut up now.  Besides, there's still some eggnog left. :-)]
--
John G Dobnick  (JGD2)
Computing Services Division @ University of Wisconsin - Milwaukee
INTERNET: [e-mail]             ATTnet: [phone]
UUCP: uunet!uwm!csd4.csd.uwm.edu!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

Volume-Number: Volume 22, Number 57

From [e-mail]  Thu Jan  3 20:37:15 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA21386; Thu, 3 Jan 91 20:37:15 -0500
Posted-Date: 27 Dec 90 14:31:08 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Donald Lewine)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Reply-To: dg![e-mail]
Organization: Data General Corporation
X-Submissions: [e-mail]
Date: 27 Dec 90 14:31:08 GMT
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Jason Zions) writes:
|>
|> I think that loosens the restriction too much.  The intent of the text, I
|> believe, is that *doing* anything between qfork() and exec*() results in
|> undefined behavior. Checking a variable doesn't *do* anything in this sense.
|> The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
|> share-memory pseudo-fork or is it a real fork or what?" An application which
|> takes an action after qfork() and before exec*() that depends upon the
|> implementation of qfork() being any one of those things is inherently
|> unportable.
|>
|> Instead of replacing "executes any code", I think you could just add the
|> phrase "which modifies memory or calls any function" and maintain the
|> intent. Examining variables doesn't depend upon the virtual memory
|> relationship between child and parent, but munging a stack for a function
|> call might behave differently and hence must be rendered undefined.
|>

    I think I would vote "NO" on qfork().  I think that there are
    two better solutions:
    (1) Just use fork() and require the implementation to do it
        in an efficient manner.
    (2) Add some new functions (fexec() ?) which do the fork() and
        exec() in one call.  I know that this is not existing practice
        but neither was sigemptyset() or tcgetispeed().  This may be
        another case where it is better to define a new interface than
        to try to describe the existing practice.  [[Also, qfork() is
        not quite vfork() so it can be shot down on the same basis.]]

    As I think about it, (2) is a much nicer solution to the problem
    than qfork().  The library can then implement fexecl() as a vfork()
    followed by an execl() or a fork() followed by an execl().  The
    error handling is clean and the semantics are obvious.


--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]

Volume-Number: Volume 22, Number 58

From [e-mail]  Fri Jan  4 19:10:50 1991
Received: from CS.UTEXAS.EDU by uunet.UU.NET (5.61/1.14) with SMTP
    id AA25247; Fri, 4 Jan 91 19:10:50 -0500
Posted-Date: 4 Jan 91 18:04:40 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Lenox H. Brassell)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Summary: MSC spawn() quite nice under OS/2
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Organization: MIT Media Lab, Cambridge, MA
X-Submissions: [e-mail]
Date: 4 Jan 91 18:04:40 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Lenox H. Brassell)

In article <[e-mail]>, [e-mail] (Guido van Rossum) writes:
> (Note that the
> spawn() functions found in Microsoft C for MS-DOS emulate either just
> exec() or fork()+exec()+wait(), which is much less powerful, but
> all that MS-DOS can support (last time I looked).)
>

Using Microsoft C under OS/2, you can pass P_NOWAIT as the first
argument to the MSC spawn() functions, and the child process will run
asynchronously.  The spawn() functions return the child process's PID
in this case.

Although MSC is certainly not a UNIX compiler, this "prior art" might
be a good place to start if POSIX needs a "safe" qfork()+exec() service.


--lenox ([e-mail])

Volume-Number: Volume 22, Number 59

From [e-mail]  Fri Jan  4 19:14:21 1991
Received: from CS.UTEXAS.EDU by uunet.UU.NET (5.61/1.14) with SMTP
    id AA25939; Fri, 4 Jan 91 19:14:21 -0500
Posted-Date: 4 Jan 91 18:26:34 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 4 Jan 91 18:26:34 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail] (Donald Lewine) writes:

>     I think I would vote "NO" on qfork().  I think that there are
>     two better solutions:
>     (1) Just use fork() and require the implementation to do it
>         in an efficient manner.

Well, I know that we POSIX folks want to rule the world, but just how
ugly a world will we put up with in order that we can rule it?  qfork()
(and vfork()) special-case a particular usage of the process creation
mechanism in order to give implementors an easier time of it.  By now we
know that in a ``from to ground up'' virtual memory implementation of
UNI*X with a half-way useful memory management hardware copy on write and
similar finessing can make the general-case fork() call as efficient as
any special-case variant, and, unlike the variants, is free from any
threat that sixteen ton weights will be dropped on any programmer who
steps out of line.

That said, POSIX has nothing to say about the efficiency of any
particular implementation: that's a quality issue, not a conformance
issue.  One hopes that in the kind of free market that standards are
supposed to encourage, better quality will win out over poorer quality,
other things being equal.  So, yes, I'm in favour of keeping just
fork(), and letting implementors worry about how slick they need to make
it.  After all, there's few implementors in this world than applications
programmers, so it seems to make sense to localize the pain involved to
the smaller group.  Sorry about that.  I am aware that the efficient
implementation of fork() is a real headache on some architectures, and
particularly in hosted POSIX, but, well, so's cooking up fake inodes
(or parts thereof).  Happily, I hear nobody suggesting that we define
unsafe versions of stat() to get around that problem.  Just how far
should we bend over backwards to accommodate history?  Remember that
every extra function we define has to be maintained on all
implementations for ever more (more or less), and that every extra
function is something else that programmers have to learn about.

>     (2) Add some new functions (fexec() ?) which do the fork() and
>         exec() in one call.  I know that this is not existing practice
>         but neither was sigemptyset() or tcgetispeed().  This may be
>         another case where it is better to define a new interface than
>         to try to describe the existing practice.  [[Also, qfork() is
>         not quite vfork() so it can be shot down on the same basis.]]

I don't like this much either, but it might be an acceptable compromise
if the effect of the new functions was defined in the standard in terms
of fork() and exec() family functions.  This would make it easy to bring
existing implementations with an efficient fork() into line.  Please
let's resist the temptation to add new functionality to exec (for
example) on the way past.

By the way, what line (if any) are the .5 (Ada) folks taking on this
issue?  How does all this square (if at all) with Ada's concept of a
task?
--
Dominic Dunlop

Volume-Number: Volume 22, Number 60

From [e-mail]  Fri Jan  4 19:21:34 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA27617; Fri, 4 Jan 91 19:21:34 -0500
Posted-Date: 4 Jan 91 19:17:07 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 4 Jan 91 19:17:07 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

( Guido lists a couple of systems where a function with spawn() type
  semantics (create a new process and load a program)... )

Also, most DEC operating systems use this sort of call for process creation.
AmigaOS does things in the opposite order: you load a segment and then use
CreateProc to start executing it.
--
Peter da Silva.   `-_-'    "Eat hot digital death, mainframe scum!"
[phone].   'U`          -- Attack of the Killer Micros.
[e-mail]

Volume-Number: Volume 22, Number 61

From [e-mail]  Sun Jan 13 13:26:01 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA09460; Sun, 13 Jan 91 13:26:01 -0500
Posted-Date: 5 Jan 91 00:43:08 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Loren L. Hart)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Sun Microsystems, Mt. View, Ca.
X-Submissions: [e-mail]
Date: 5 Jan 91 00:43:08 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Loren L. Hart)

In article <[e-mail]> [e-mail] (Guido van Rossum) writes:
>Submitted-by: [e-mail] (Guido van Rossum)
>
>[e-mail] (Peter da Silva) writes:
>
>>Yes, fork() is a cleaner method of creating new processes. Yes, it takes
>>a fairly complex calling sequence to get spawn() to have anything like
>>the functionality of fork()...exec(). But I think it'd be worthwhile to
>>let a little heresy in in exchange for making POSIX more palatable to
>>folks in poorer environments.
>
>I know of precedents even in OS'es that support fork(): Amoeba and
>Topaz support a variant of what you call spawn().  (Note that the
>spawn() functions found in Microsoft C for MS-DOS emulate either just
>exec() or fork()+exec()+wait(), which is much less powerful, but
>all that MS-DOS can support (last time I looked).)

The Ada POSIX Draft currently has some sort of spawn command, since
fork is not necessicarily safe with respect to Ada Tasks.  I don't rember
the specific routine, but it is likely to go through some change before
the Ada version of the standard is finalized.  I would hope that this
spawn capability will be merged back into the 1003.1 standard at some
point in the future.

------------------------------------------------------------
Mr. Loren L. Hart
The Ada Ace Group, Inc.
PO Box 36195
San Jose, CA  95158
[e-mail]

--
-----------------------------------------------------------------------------
Loren L. Hart            The Ada Ace Group, Inc
[e-mail]        P.O. Box 36195
                San Jose, CA  95158


Volume-Number: Volume 22, Number 62

From [e-mail]  Sun Jan 13 13:36:57 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA10394; Sun, 13 Jan 91 13:36:57 -0500
Posted-Date: 6 Jan 91 14:17:09 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: Finding physical memory size
Summary: sometimes it is.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
X-Submissions: [e-mail]
Date: 6 Jan 91 14:17:09 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

    sometimes knowing physical memory size, or at least
what is left over for user programs, is useful. particularly
for user programs which manage their own memory. although
what is actually meant here is how much memory do i have
really quick efficent access to.

Volume-Number: Volume 22, Number 63

From [e-mail]  Sun Jan 13 13:42:44 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA10860; Sun, 13 Jan 91 13:42:44 -0500
Posted-Date: 7 Jan 91 04:21:51 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Masataka Ohta)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Tokyo Institute of Technology
X-Submissions: [e-mail]
Date: 7 Jan 91 04:21:51 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Masataka Ohta)

>By now we
>know that in a ``from to ground up'' virtual memory implementation of
>UNI*X with a half-way useful memory management hardware copy on write and
>similar finessing can make the general-case fork() call as efficient as
>any special-case variant, and, unlike the variants, is free from any
>threat that sixteen ton weights will be dropped on any programmer who
>steps out of line.

You should also know that copy-on-write fork(), unlike vfork(), is inherently
buggy and can not be a general-purpose useful memory management mechanism.

If you have 50MB swap space and want to fork() 30MB process to exec less
than 1MB shell, you can't. With COW fork(), there is workaround. But the
workaround is so incomplete that the system sometimes deadlocks.

Thus, fork(), even COW fork(), is not a proper mechanism to fork-exec
other processes.

If you insist on using fork(), someday, thirtytwo ton weights will drop on
your head.

                        Masataka Ohta

PS

I can't understand why the name vfork() is changed to qfork(). On crippled
systems which can not support true vfork(), the implementors can make vfork()
just fork(). It is actually done on NeXT. What's wrong with that?

Volume-Number: Volume 22, Number 64

From [e-mail]  Sun Jan 13 13:49:59 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA11735; Sun, 13 Jan 91 13:49:59 -0500
Posted-Date: 7 Jan 91 22:23:23 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Bob Lenk)
Newsgroups: comp.std.unix
Subject: Re: Finding physical memory size
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 7 Jan 91 22:23:23 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Bob Lenk)

In article <[e-mail]>, [e-mail] (John G Dobnick) writes:

>    Was consideration given to including some mechanism to retrieve
>    hardware configuration information via 'standard' means?

Not much.  Remember that the purpose of POSIX.1 was to define interfaces
for portable applications.  There is little if any use that a portable
application can make of such information.

Through the trial use standard (1986) there was an appendix (Appendix H)
requiring each system to supply some such information off-line.  That
appendix was dropped in the first draft following trial use; the
portions deemed useful were made available via interfaces like
sysconf(), pathconf(), <limits.h>, and <unistd.h>.

        Bob Lenk
        [e-mail]
        {uunet,hplabs}!fc.hp.com!rml

Volume-Number: Volume 22, Number 65

From [e-mail]  Sun Jan 13 13:54:00 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA12968; Sun, 13 Jan 91 13:54:00 -0500
Posted-Date: 7 Jan 91 22:15:46 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 7 Jan 91 22:15:46 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>I think that loosens the restriction too much.  The intent of the text, I
>believe, is that *doing* anything between qfork() and exec*() results in
>undefined behavior. Checking a variable doesn't *do* anything in this sense.
>The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
>share-memory pseudo-fork or is it a real fork or what?"

We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
because it was not necessary, given a decent implementation of fork().
Why is this notion being reintroduced (quite carelessly so far as I can
tell from the quotes so far) for 1003.1a?

Volume-Number: Volume 22, Number 66

From [e-mail]  Mon Jan 14 05:55:20 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA15233; Mon, 14 Jan 91 05:55:20 -0500
Posted-Date: 14 Jan 91 04:34:31 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (John F Haugh II)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
X-Submissions: [e-mail]
Date: 14 Jan 91 04:34:31 GMT
To: [e-mail]

Submitted-by: [e-mail] (John F Haugh II)

In article <[e-mail]> [e-mail] (Masataka Ohta) writes:
>You should also know that copy-on-write fork(), unlike vfork(), is inherently
>buggy and can not be a general-purpose useful memory management mechanism.

You are confusing theory with implementation.  There is nothing "inherently"
buggy with either vfork() or copy-on-write fork().  vfork() is fairly
inflexible, and as pointed out by other writers, completely superfluous
given a properly implemented fork().

>If you have 50MB swap space and want to fork() 30MB process to exec less
>than 1MB shell, you can't. With COW fork(), there is workaround. But the
>workaround is so incomplete that the system sometimes deadlocks.

Again, the problem you are alluding to results from the choice of early
or late allocation of paging space.  If you choose early allocation, you
are correct - you can't fork() a 30MB process with only 20MB remaining.
And yes, if you choose late allocation it is possible to deadlock, but
only in the cases where you are doing more than you are with vfork().
Thus your complaint is simply invalid.  If I modify no pages between
fork() and exec() with late allocated COW fork(), I will =never= run
out of page space simply because I required no additional pages.  Any
scenario where I do modify a page is unsuitable for vfork(), so there
is no room for comparision of the merits of fork() with vfork().

>Thus, fork(), even COW fork(), is not a proper mechanism to fork-exec
>other processes.

If you wish to describe some operation which is a simple fork-exec
then you are correct.  However, process creation frequently involves
more than forking and execing a new command.  It often involves the
creation of IPC mechanisms (pipes, etc), signal manipulation, I/O
redirection, ad nauseum.
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."

Volume-Number: Volume 22, Number 67

From [e-mail]  Wed Jan 16 22:57:53 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA19684; Wed, 16 Jan 91 22:57:53 -0500
Posted-Date: 14 Jan 91 14:19:09 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork() (the spawn of Spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 14 Jan 91 14:19:09 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
> because it was not necessary, given a decent implementation of fork().

POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
environments a "decent implementation of fork" is quite difficult and
may even be impossible. A poor implementation of fork() is likely to
clobber performance, given how common it is in UNIX code.

I suspect that in practice most implementations will use an efficient
call in the internals of system() and similar library routines. Either
direct spawns or an implementatio of qfork that looks something like:

    qfork()
    {
        Save stack context.
        Vector open(), exit(), etc to pseudo routines that
            save flags (either adjust jump table or set
            a flag that tells open we're "in a qchild".
        Return 0;
    }

    qopen() /* new version of open */
    {
        open file, save descriptor
    }
    ...

    qexec() /* new version of exec */
    {
        call spawn, passing it the info for the new execution
            environment (juggling fds, signals, etc).
        Return execution environment to the one set up back
            at the qfork (juggle fds, etc)
        longjump back to saved stack context, returning child pid.
    }

This gets around the cost of creating a new execution context that will
simply be juggled briefly and discarded.

Something like this will be needed to get decent performance out of systems
like VMS where creating a new process is quite expensive. Why not standardise
this so portable programs can take advantage of it?
--
Peter da Silva.   `-_-'   "Have you hugged your wolf today?"
[phone].   'U`
[e-mail]

Volume-Number: Volume 22, Number 68

From [e-mail]  Wed Jan 16 23:11:58 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA21388; Wed, 16 Jan 91 23:11:58 -0500
Posted-Date: 14 Jan 91 18:21:56 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 14 Jan 91 18:21:56 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

For those who have been following this issue, last week's meeting of
1003.1 decided that [qv]fork() would be dropped from the next draft of
1003.1a, the extensions to POSIX.1.  It will be replaced in the next
or a subsequent draft with a proposal for a spawn() family, analogous to
the exec() family.  Work already done by 1003.5 (Ada bindings) on an
interface of this type will be taken into account, and the opportunity
will be taken to address some very knotty problems which arise when one
thread out of many in a single process decides to replace the whole
process image.  Threads are strictly a 1003.4 (realtime) issue, but it
makes sense for any new interface proposed by 1003.1 in this area
make life easier for 1003.4, rather than more difficult.  (Cue 1003.4
folks, to tell us all what a pig fork-exec is in a multi-threaded
process.)
--
Dominic Dunlop

Volume-Number: Volume 22, Number 69

From [e-mail]  Wed Jan 16 23:21:29 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA22583; Wed, 16 Jan 91 23:21:29 -0500
Posted-Date: 14 Jan 91 20:14:05 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Richard Tobin)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
X-Submissions: [e-mail]
Date: 14 Jan 91 20:14:05 GMT
To: [e-mail]

Submitted-by: [e-mail] (Richard Tobin)

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
>Any scenario where I do modify a page is unsuitable for vfork(), so there
>is no room for comparision of the merits of fork() with vfork().

Most programs that use vfork() change the values of variables in the
child.  This is perfectly reasonable, so long as the parent doesn't
rely on the value of those variables.

Of course, these programs don't usually change many variables, so a
copy-on-write fork() won't need many pages in this case.  A c-o-w
fork() with late allocation of pages could could be as robust as
vfork() almost always by pre-allocating a few pages.

Surely the problem is when it's being used as a *real* fork(), and the
program fails much later when it modifies one variable too many.

I prefer to think of vfork() as being a way to save a process's kernel
state - file descriptors etc - and having that state automatically
restored when an exec() is done.

-- Richard
--
Richard Tobin,                       JANET: [e-mail]
AI Applications Institute,           ARPA:  [e-mail]
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin

Volume-Number: Volume 22, Number 70

From [e-mail]  Wed Jan 16 23:30:57 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA23693; Wed, 16 Jan 91 23:30:57 -0500
Posted-Date: 15 Jan 91 20:07:39 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Tom Jordahl)
Newsgroups: comp.std.unix
Subject: Where can I find a recent (Draft 10-11) PAX?
Summary: looking for a recent version of pax.
Keywords: pax POSIX 1003.2
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Open Software Foundation
X-Submissions: [e-mail]
Date: 15 Jan 91 20:07:39 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Tom Jordahl)

Hopefully this is the correct forum for this post.

Could someone give me a pointer to a recent (Draft 10 based) version of
the 1003.2 pax archive utility.

I have the one written by Mark H. Colburn ([e-mail]) at
release 1.2, but this is dated 13 Feb 1989, almost 2 years old.
I found this on uunet.uu.net in the comp.sources.unix archives.

Has pax changed much in the past two years?  I haven't compared my
Draft 10 .2 with any earlier drafts, but practically the whole
section is marked with change-marks.

I have tried to reach Mark, even calling the phone number given in the
distribution. [Don't! the guy on the other end seemed pretty POed
when I asked for Mark, saying he hadn't lived there in 'several
years'.  He complained about people calling from Washington and
leaving message for him to call them back....]

I have also tried reaching him via E-mail, but have gotten no response.

Any help would be appreciated.  Thanks.

--

Tom Jordahl                                       Internet: [e-mail]
Open Software Foundation                          UUCP:   ..!uunet!osf!tom
       "A silly quote is only worth what you put into it."  -- me

Volume-Number: Volume 22, Number 71

From [e-mail]  Thu Jan 17 01:07:57 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA06553; Thu, 17 Jan 91 01:07:57 -0500
Posted-Date: 15 Jan 91 21:24:11 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Bob Lenk)
Newsgroups: comp.std.unix
Subject: Re: qfork() (The Spawn of spawn())
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 15 Jan 91 21:24:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Bob Lenk)

In article <[e-mail]> [e-mail] (John F Haugh II) writes:

> Again, the problem you are alluding to results from the choice of early
> or late allocation of paging space.  If you choose early allocation, you
> are correct - you can't fork() a 30MB process with only 20MB remaining.
> And yes, if you choose late allocation it is possible to deadlock, but
> only in the cases where you are doing more than you are with vfork().

This sounds like a good argument for two mechanisms, one with early
allocation and the other with late (or perhaps no) allocation.  If the
OS chooses blindly from a single interface (fork) it will sometimes
choose "wrong" according to the needs of the application.  There could
be an interface to select the behavior of fork() rather than two
separate calls; there are some advantages to each approach.

In what I've read in this discussion about qfork(), I'm nervous about
the spec that *nothing* is permitted between it and exec.  If nothing is
permitted portably, then a single spawn call should be defined.  The
whole advantage of separate calls is that things *can* be done in
between.  People will take advantage of this even if the standard calls
the behavior implementation-defined, unspecified, or undefined, and the
result is that people will write less-than-portable code.  If the
standard defines qfork(), I think it should define a useful set of
operations permitted with well-defined results in the child prior to
exec.

        Bob Lenk
        [e-mail]
        {uunet,hplabs}!fc.hp.com!rml

Volume-Number: Volume 22, Number 72

From [e-mail]  Thu Jan 17 03:14:52 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA04545; Thu, 17 Jan 91 03:14:52 -0500
Posted-Date: 14 Jan 91 14:19:09 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork() (the spawn of Spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 14 Jan 91 14:19:09 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
> because it was not necessary, given a decent implementation of fork().

POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
environments a "decent implementation of fork" is quite difficult and
may even be impossible. A poor implementation of fork() is likely to
clobber performance, given how common it is in UNIX code.

I suspect that in practice most implementations will use an efficient
call in the internals of system() and similar library routines. Either
direct spawns or an implementatio of qfork that looks something like:

    qfork()
    {
        Save stack context.
        Vector open(), exit(), etc to pseudo routines that
            save flags (either adjust jump table or set
            a flag that tells open we're "in a qchild".
        Return 0;
    }

    qopen() /* new version of open */
    {
        open file, save descriptor
    }
    ...

    qexec() /* new version of exec */
    {
        call spawn, passing it the info for the new execution
            environment (juggling fds, signals, etc).
        Return execution environment to the one set up back
            at the qfork (juggle fds, etc)
        longjump back to saved stack context, returning child pid.
    }

This gets around the cost of creating a new execution context that will
simply be juggled briefly and discarded.

Something like this will be needed to get decent performance out of systems
like VMS where creating a new process is quite expensive. Why not standardise
this so portable programs can take advantage of it?
--
Peter da Silva.   `-_-'   "Have you hugged your wolf today?"
[phone].   'U`
[e-mail]

Volume-Number: Volume 22, Number 68

From [e-mail]  Thu Jan 17 09:49:55 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA01691; Thu, 17 Jan 91 09:49:55 -0500
Posted-Date: 17 Jan 91 05:11:55 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: qfork() (the spawn of Spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 17 Jan 91 05:11:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
>> because it was not necessary, given a decent implementation of fork().
>POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
>environments a "decent implementation of fork" is quite difficult ...

Excuse me, but you're quite wrong.  P1003 decided deliberately that we
(I was there) would not compromise the (1003.1) interface in order to
accommodate "layered" implementations, for example on non-UNIX based
operating system kernels.

Volume-Number: Volume 22, Number 73

From [e-mail]  Thu Jan 17 09:55:29 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA02706; Thu, 17 Jan 91 09:55:29 -0500
Posted-Date: 17 Jan 91 12:34:20 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] ("C.R. Ritson")
Newsgroups: comp.std.unix
Subject: Shell standardization (for c.std.unix)
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 17 Jan 91 12:34:20 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] ("C.R. Ritson")

Please  could  you  post  this  to  comp.std.unix, or else reply to it
yourself if that is more appropriate.

                               -------

I  am  unsure  of the state of standardisation of the unix shells, but
hope that the standards committees would consider removing a piece  of
functionality that is becoming both irrelevant and dangerous.

I  am  thinking of the feature where, after the exec system call fails
to be able to execute a file, the shell assumes that  if  it  has  the
execute  bit  set  and is a file, then it must be a shell script.  Now
that the exec  system  call  on  most  systems  understands  the  "#!"
notation  as  a  valid  magic  number and starts the named interpretor
itself, this is no  longer  needed,  provided  this  behaviour  itself
becomes standard.

The  danger  of direct interpretation by the shell is that the file is
quite  likely  to  be  an  executable  object  file  for  some   other
architecture  seen  from the wrong side of an NFS mount.  When this is
the case the shell produces large numbers of "not found" messages  and
often  ends  up  resetting  numerous operating modes.  Our newer users
find this most confusing.

Chris Ritson
--
PHONE: [phone]              Computing Laboratory,
FAX  : [phone]              University of Newcastle upon Tyne,
TELEX: uk+53654-UNINEW_G            UK, NE1 7RU

Volume-Number: Volume 22, Number 74

From [e-mail]  Fri Jan 18 15:24:25 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA23737; Fri, 18 Jan 91 15:24:25 -0500
Posted-Date: 17 Jan 91 20:30:50 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: qfork() (the spawn of Spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 17 Jan 91 20:30:50 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

I said:
> >POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
> >environments a "decent implementation of fork" is quite difficult ...

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> Excuse me, but you're quite wrong.  P1003 decided deliberately that we
> (I was there) would not compromise the (1003.1) interface in order to
> accommodate "layered" implementations, for example on non-UNIX based
> operating system kernels.

I don't think I'm wrong here, unless you're leaving something out.

There's a difference between:

    P1003 will not compromise the interface to accomodate
    layered implementations.

And:

    P1003 is for UNIX only.

And I fail to see how an extension that happens to make it easier to
write portable programs that remain reasonably efficient on layered
implementations compromises the interface. Nobody's saying "get rid
of fork()" this time.
--
Peter da Silva.  `-_-'  [e-mail]
[phone].  'U`  "Have you hugged your wolf today?"

Volume-Number: Volume 22, Number 75

From [e-mail]  Fri Jan 18 15:29:08 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA24939; Fri, 18 Jan 91 15:29:08 -0500
Posted-Date: 17 Jan 91 20:44:54 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Tom Truscott)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Summary: Fix missing-#! problem with kernel (or shell) check, not lobotomy
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: MCNC; RTP, NC
X-Submissions: [e-mail]
Date: 17 Jan 91 20:44:54 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Tom Truscott)

> Submitted-by: [e-mail] ("C.R. Ritson")
>
> ...
> The  danger  of direct interpretation by the shell is that the file is
> quite  likely  to  be  an  executable  object  file  for  some   other
> architecture  seen  from the wrong side of an NFS mount.  When this is
> the case the shell produces large numbers of "not found" messages  and
> often  ends  up  resetting  numerous operating modes.  Our newer users
> find this most confusing.

If the kernel simply returned EACCES (for example) rather than ENOEXEC
when the file is non-ascii, the shells would not attempt interpretation.
(Just check that the first 4 characters have value > 1 and < 128.)
Dropping direct interpretation does make good sense.
But there is the problem of old kernels (e.g. System V.3.2!!) lacking #!,
and I think a surprising number of scripts will stop working
(such as /bin/true on some systems).  Serves them right I suppose.

For Freedomnet, we took this a bit further.  We identify
the binary's type and then execute it on the fastest available system.
This saves a lot of wear and tear in our user environment
with computers from a dozen different vendors.
Wherever I log in my favorite commands still work.
(Hmm, would other people have a dozen different personal "bin" directories?)
Of course this isn't entirely wonderful: when we unplugged the last
Gould machine some of my commands had to be recompiled.
But it goes a long way and surely it is in the right direction.

It is ironic that this NFS comment comes from the home of
the Newcastle Connection, which is the intellectual parent
of Freedomnet.  We kept the faith, and the technical
results have been most gratifying.
You too can get religion: contact Thomas Warren at 1-919-541-6110
or [e-mail].

    Tom Truscott

Volume-Number: Volume 22, Number 76

From [e-mail]  Sat Jan 19 17:31:21 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA00586; Sat, 19 Jan 91 17:31:21 -0500
Posted-Date: 19 Jan 91 01:54:54 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dik T. Winter)
Newsgroups: comp.std.unix
Subject: Standard behaviour when searching libraries
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: CWI, Amsterdam
X-Submissions: [e-mail]
Date: 19 Jan 91 01:54:54 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dik T. Winter)

As I do not have access to any of the current or forthcoming standards, I ask
this question here.  Is it defined anywhere what the behaviour of the loader
is in the load step with respect to libraries?  Especially is there any
difference between a full path specification of the library or a short hand
specification using -l?  I ask because I encountered a system that showed a
marked difference between:
    cc foo.c /usr/lib/libm.a
and:
    cc foo.c -lm
In the first case the complete library is linked into the object module,
in the second only the routines needed are linked in.
Does any standard say something about this (SVID, Posix)?
--
dik t. winter, cwi, amsterdam, nederland
[e-mail]

Volume-Number: Volume 22, Number 77

From [e-mail]  Mon Jan 21 22:15:09 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA16359; Mon, 21 Jan 91 22:15:09 -0500
Posted-Date: 21 Jan 91 10:33:48 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Jack Jansen)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 21 Jan 91 10:33:48 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jack Jansen)

>  = [e-mail] (Tom Truscott) writes:
>> = [e-mail] ("C.R. Ritson")
>> The  danger  of direct interpretation by the shell is that the file is
>> quite  likely  to  be  an  executable  object  file  for  some   other
>> architecture  seen  from the wrong side of an NFS mount.  When this is
>> the case the shell produces large numbers of "not found" messages  and
>> often  ends  up  resetting  numerous operating modes.  Our newer users
>> find this most confusing.

>If the kernel simply returned EACCES (for example) rather than ENOEXEC
>when the file is non-ascii, the shells would not attempt interpretation.
>(Just check that the first 4 characters have value > 1 and < 128.)
>Dropping direct interpretation does make good sense.
>But there is the problem of old kernels (e.g. System V.3.2!!) lacking #!,
>and I think a surprising number of scripts will stop working
>(such as /bin/true on some systems).  Serves them right I suppose.

I think you've missed the point here. The question is not wether the
kernel recognizes #!, but wether the shell recognizes it.

Currently, when the kernel returns ENOEXEC the shell just blindly assumes
that we have a shell script here and starts executing it. I don't see
any problem in the shell reading the first line and checking it for
#!/bin/sh.

The only thing that this would break is that old shell scripts without
a #! first line wouldn't execute anymore, but this is trivial to fix
by adding the #! line.
--
--
Een volk dat voor tirannen zwicht    | Oral:     Jack Jansen
zal meer dan lijf en goed verliezen    | Internet: [e-mail]
dan dooft het licht            | Uucp:     hp4nl!cwi.nl!jack


Volume-Number: Volume 22, Number 78

From [e-mail]  Mon Jan 28 20:41:53 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA28266; Mon, 28 Jan 91 20:41:53 -0500
Posted-Date: 22 Jan 91 21:28:49 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: auspex![e-mail] (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Auspex Systems, Santa Clara
X-Submissions: [e-mail]
Date: 22 Jan 91 21:28:49 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Guy Harris)

>Currently, when the kernel returns ENOEXEC the shell just blindly assumes
>that we have a shell script here and starts executing it. I don't see
>any problem in the shell reading the first line and checking it for
>#!/bin/sh.

Or checking for "#!" in general, and doing what is done in the "exec*()"
implementations of many systems (usually in the kernel, but not
necessarily so) - i.e., have the Bourne shell capable of executing C
shell scripts (for those of you who write them :-)) that begin with "#!
/bin/csh", and the C shell capable of executing Bourne shell scripts
that begin with "#! /bin/sh", etc..

I don't strongly care where it's done (although I *do* prefer having
"execl()" AND "execv()" capable of running scripts, even if it's done by
having them be wrappers around kernel traps with the wrappers checking
for the "#!" line if they get ENOEXEC), but it *would* be nice if the
system didn't inappropriately try to run files that happened to have
execute permissions as scripts if, in fact, they aren't scripts.

I don't know if anything more should be said by any standard than simply
"we do not guarantee that any shell will execute a script that doesn't
begin with '#!'", so that you can remove the "if it gets ENOEXEC, treat
it as a script" stuff and still comply with the appropriate POSIX
standard(s).


Volume-Number: Volume 22, Number 79

From [e-mail]  Mon Jan 28 20:44:41 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA29276; Mon, 28 Jan 91 20:44:41 -0500
Posted-Date: 23 Jan 91 23:57:04 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 23 Jan 91 23:57:04 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Jack Jansen) writes:
>I don't see any problem in the shell reading the first line and
>checking it for #!/bin/sh.

Shells that have done this (e.g. some csh implementations on UNIX System V)
have definitely caused problems.  For example, Most of my shell scripts
start with #!/usr/5bin/sh to ensure System V semantics on BSD systems;
however, on a genuine UNIX System V system I was expecting the script to
be interpreted by /bin/sh (even if executed by csh).  We discovered that
some overly-"helpful" implementations of csh on System V, however, went
ahead and tried to find /usr/5bin/sh, which of course made the execution
fail.

Volume-Number: Volume 22, Number 80

From [e-mail]  Mon Jan 28 20:55:08 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA03650; Mon, 28 Jan 91 20:55:08 -0500
Posted-Date: 23 Jan 91 10:06:36 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Alain Williams)
Newsgroups: comp.std.unix
Subject: Re: qfork() (the spawn of Spawn())
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Parliament Hill Computers Ltd
X-Submissions: [e-mail]
Date: 23 Jan 91 10:06:36 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Alain Williams)

> There's a difference between:
>
>     P1003 will not compromise the interface to accomodate
>     layered implementations.
>
> And:
>
>     P1003 is for UNIX only.
>
> And I fail to see how an extension that happens to make it easier to
> write portable programs that remain reasonably efficient on layered
> implementations compromises the interface. Nobody's saying "get rid
> of fork()" this time.
OK, so you are writing a program that you intend to port onto every Posix
machine in the universe. Do you use fork()/exec() or do you use spawn() ?

If you are writing the system(3C) function the answer is easy, if your
application does a little more work in between fork() & exec(), do you jump
though hoops to use whatever spawn() turns out to be and ``damage'' your
implementation on true UNIX boxes for a new non-UNIX ones ?

I guess that what you would do is to use good old #ifdef to get the best of
both worlds. So I don't think that it really matters what we end up with
as long as the fork()/exec() alternative is well defined so that we only have
to do the non-UNIX posix port once.

What would be probably quite usefull is a
    #define FORK_IS_PAINFULL
that we can test and thus compile in the spawn() code.

You should not forget that these standards are supposed to make life
easier for application writer. Also the (good) application writer takes a
pragmatic approach and does the best job that he can in a given environment,
the most important thing is to get it working reasonably well - and quickly.

Alain Williams

[phone]

phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.

Volume-Number: Volume 22, Number 81

From [e-mail]  Mon Jan 28 21:12:51 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA12149; Mon, 28 Jan 91 21:12:51 -0500
Posted-Date: 26 Jan 91 22:24:36 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dick Dunn)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Summary: not trivial
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Interactive Systems Corporation, Boulder, CO
X-Submissions: [e-mail]
Date: 26 Jan 91 22:24:36 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dick Dunn)

[e-mail] (Jack Jansen) writes:

> ... I don't see any problem in the shell reading the first line and
> checking it for #!/bin/sh.

> The only thing that this would break is that old shell scripts without
> a #! first line wouldn't execute anymore, but this is trivial to fix
> by adding the #! line.

While I don't really intend to wish evil upon Jansen, I do wish that people
who make statements like this would have to keep a hand in maintaining
large systems.

It is, indeed, trivial to change any given shell script by the addition of
a #! line at the beginning.  But the task of finding (all instances of) all
shell scripts and correcting them all is a most incredible nightmare.  Even
this ignores finding the programs which generate shell scripts (a much
smaller class than the former, but much harder to solve).

The alternate solution which has been suggested--having the shell sanity-
check before it executes a file--is far more practical to carry out in the
real world, and will find virtually all non-shell-script problems.
--
Dick Dunn     [e-mail] -or- ico!rcd       Boulder, CO   [phone]
   ...Mr. Natural says, "Use the right tool for the job."

Volume-Number: Volume 22, Number 83

From [e-mail]  Mon Jan 28 21:14:22 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA12889; Mon, 28 Jan 91 21:14:22 -0500
Posted-Date: 23 Jan 91 21:37:00 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: recent history of Unix evolution
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 23 Jan 91 21:37:00 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

I am writing a small article which touches on recent evolution in Unix
standards, but can't seem to find some information that it would be nice to
include.  I would appreciate it if some kind soul who is up on all of this
could please shed a little light on this for me.

Questions:

1.AT&T, Sun and Microsoft banded together in the late 80's to create System V.4
    as the merge of the System V.3, SunOS, and Xenix strains of Unix.
    What was the duration of the software development phase, and what were the
    release dates of System V.4 on each significant platform?

2.Similarly, OSF/1 is "currently under development" but is having some problems
    getting off the ground.  I believe IBM has pulled out of the effort to
    develop the operating system, in favour of AIX which works.  What are the
    dates of:    1.the formation of OSF
                 2.the development phase of the OSF/1 operating system
                   (is it still under development, or  has it been abandoned
                     completely after the pull out by Big Blue?)
    What are the Unix roots of the OSF/1 operating system?  i.e. was it
    developed from System V.2, or Mach from Carnegie Mellon U?

3.What is the date of the formation of UI (Unix International)?

4.What are the Unix roots of AIX?  i.e. was it developed from System V.2 or
    Mach?  What are its advantages and disadvantages relative to other
    strains of Unix?

3.What are the Unix roots of Mach?  Why did Carnagie Melon develop it?  What
    are its advantages and disadvantages relative to other strains of Unix?
    (i.e. why did Next (and possibly IBM?) choose Mach over BSD or some
     other flavour of Unix?)

4.Is there a competition between System V.4 and OSF/1, in the sense that one
    will be chosen as the ANSI standard Unix, or are they both sufficiently
    conformant to current ANSI/POSIX standards, that this is not an issue:
    that the competition is strictly in the marketplace?

I realise this is a lot to ask, but I can't find this information in any of
our locally available references.  RTFM responses, or references to articles
in recent publications welcome.

with thanks in anticipation,

Kevin Broekhoven                     Computing Centre
applications programmer              Queens University K7L-3N6 (Canada)
Bitnet, NetNorth: BROEKHVN@QUCDN     IP: [e-mail] (130.15.48.9)
X.400:  [e-mail]  Bell: [phone] fax: [phone]

Volume-Number: Volume 22, Number 84

From [e-mail]  Mon Jan 28 21:29:06 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA18673; Mon, 28 Jan 91 21:29:06 -0500
Posted-Date: 25 Jan 91 03:25:13 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (michael gersten)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: UCLA Computer Science Department
X-Submissions: [e-mail]
Date: 25 Jan 91 03:25:13 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (michael gersten)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>Submitted-by: [e-mail] (Doug Gwyn)
>
>In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>>In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>>> We (IEEE P1003) deliberately omitted vfork() from the POSIX spec
>>> because it was not necessary, given a decent implementation of fork().
>>POSIX is not supposed to be a standard for UNIX only. In many non-UNIX
>>environments a "decent implementation of fork" is quite difficult ...
>
>Excuse me, but you're quite wrong.  P1003 decided deliberately that we
>(I was there) would not compromise the (1003.1) interface in order to
>accommodate "layered" implementations, for example on non-UNIX based
>operating system kernels.


May I humbly ask what was wrong with vfork?

As I understand it, vfork's semantics was a virtual fork--
conceptually two execution threads would return from the call,
and they may or may not be sharing data space--any program
that relied on one or the other was by definition broken.

Now, with that definition, vfork() is pretty trivial to implement,
even on a naked 68000 with no mmu. And on better, more complete
systems, it can be identical to fork.

So its a call that is at least, if not more, efficient on a larger
variety of hardware platforms.

Now, why was it removed? What is wrong with it?

Volume-Number: Volume 22, Number 82

From [e-mail]  Tue Jan 29 16:58:39 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA14672; Tue, 29 Jan 91 16:58:39 -0500
Posted-Date: 29 Jan 91 06:55:06 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Kithrup Enterprises, Ltd.
X-Submissions: [e-mail]
Date: 29 Jan 91 06:55:06 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (michael gersten) writes:
>So its a call that is at least, if not more, efficient on a larger
>variety of hardware platforms.
>Now, why was it removed? What is wrong with it?

Why have it at *all*?  If it is functionally equivalent to fork(), why in
k&r's name add another call that does exactly the same thing?

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 85

From [e-mail]  Wed Jan 30 18:30:36 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19836; Wed, 30 Jan 91 18:30:36 -0500
Posted-Date: 30 Jan 91 01:54:04 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: lupine![e-mail] (Ron Guilmette)
Newsgroups: comp.std.unix
Subject: Is there a standard prototype for `execvp'?
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Network Computing Devices, Inc., Mt. View, CA
X-Submissions: [e-mail]
Date: 30 Jan 91 01:54:04 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Ron Guilmette)

It is somewhat dated now, but the only book I have about POSIX is
copyright 1988.

Reading that book, it seems that the POSIX committee didn't want to
use ANSI C function prototypes for their specification of the C language
binding because prototypes were too "new-fangled".  Specifically, they
apparently choose not to express the binding in terms of prototypes because:

    "... the Working Group was aware that some vendors would wish
    to implement POSIX in terms of a binding to an historical
    variant of the C language..."

So in effect, it seems that the bindings given in the book I'm looking
at are for "traditional C" (rather than ANSI C).

In addition to avoiding prototypes, the POSIX folks also (apparently)
decided to avoid the use of ANSI C type qualifiers (i.e. "const" and
"volatile") in the C binding.

Now even thought I don't really keep up on such things, I assume that
some progress has been made since 1988.  Is there now also an ANSI C
binding for POSIX?  If so, please tell me the exact name of *that*
document so that I can go buy a copy.

The thing that I most want to know at the moment is the "correct" (or
"standard") prototype for the `execvp' function.  The POSIX book I have
here doesn't use any ANSI C type qualifiers at all, and so I have no
idea what (if any) type qualifiers should be used to declare the types
of the formal parameters for execvp.

For example, my intuition tells me that a "proper" prototype for `execvp'
should look like:

    extern int execvp (const char *, const char *const *);

But somebody else disagrees with me.

It seems that this sort of thing could be an important "standards" issue
because many variants of UN*X operating systems are now shipping with fully
prototyped system include files.  Are they "POSIX-conformant" with respect
to the qualifiers used to declare the types of their formals?  How would
one be able know one way or the other?

Please excuse me if this has all been resolved long ago (and if my nearly
total ignorance is showing).

Volume-Number: Volume 22, Number 87

From [e-mail]  Wed Jan 30 18:40:35 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22669; Wed, 30 Jan 91 18:40:35 -0500
Posted-Date: 30 Jan 91 14:29:14 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Peter Salus)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: The World @ Software Tool & Die
X-Submissions: [e-mail]
Date: 30 Jan 91 14:29:14 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Salus)

In article <[e-mail]> [e-mail] writes:
>Submitted-by: [e-mail]
>
>I am writing a small article which touches on recent evolution in Unix
>standards, but can't seem to find some information that it would be nice to
>include.  I would appreciate it if some kind soul who is up on all of this
>could please shed a little light on this for me.
>
Much of what you ask is in Libes&Ressler, Life with UNIX,
Prentice Hall 1989.  For the stuff on Mach, I suggest the
Summer 1986 (Atlanta) USENIX Proceedings or the Proceedings
of the USENIX Mach Workshop last Autumn.  OSF was created in
May 1989; UI (in response) in August/September 1989.  There
are two OSF papers and a Mach paper in the USENIX Proceedings
for Dallas (last week).

P
--
The difference between practice and theory in practice is always
greater than the difference between practice and theory in theory.

Volume-Number: Volume 22, Number 89

From [e-mail]  Wed Jan 30 18:46:23 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24120; Wed, 30 Jan 91 18:46:23 -0500
Posted-Date: 30 Jan 91 17:55:07 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Summary: #!/bin/whatever
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Mindcraft, Inc.
X-Submissions: [e-mail]
Date: 30 Jan 91 17:55:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail] (Doug Gwyn) wrote:
>In article <[e-mail]> [e-mail] (Jack Jansen) writes:
>>I don't see any problem in the shell reading the first line and
>>checking it for #!/bin/sh.
>
>Shells that have done this (e.g. some csh implementations on UNIX System V)
>have definitely caused problems.  For example, Most of my shell scripts
>start with #!/usr/5bin/sh to ensure System V semantics on BSD systems;
>however, on a genuine UNIX System V system I was expecting the script to
>be interpreted by /bin/sh (even if executed by csh).

It would seem that programmer expectations were more at fault here than
were the SysV shells.  The scripts he described were designed to
exploit a difference in the behavior of shells on different systems.  I
don't understand why it worked, though.  On some older SysV-based
systems I've used, scripts that start with the '#' character are
interpreted as csh scripts no matter what follows the '#'.

Some systems that honor "#! /bin/whatever" do not default to csh if the
file starts with just "#".

The need for a hard-coded path makes scripts that depend on the "#!"
mechanism non-portable. "/usr/5bin/sh" is the right path for a shell
with full SysV functionality on a Sun.  On a DEC system, the
incantation is "/bin/sh5"; on other systems, the correct name might be
"/usr/usg/sh" or "/bin/bsh".  Perhaps what we need is a standard set of
non-filename identifiers for shells.

Creative use of links can help alleviate this problem on existing
systems.

I would be more optimistic that the adoption of the 1003.2 standard
would solve this problem if I hadn't already seen the many different
ways that vendors have isolated 1003.1 behavior in compatibility
modes.  Operating system standards won't live up to their full
potential until they're accepted as the default interfaces.

To change the subject a little, what features of modern sh
implementations cause scripts written for the BSD sh to fail?  I
presume there's a reason that BSD vendors don't install a SysV sh in
/bin.  Followups on this point should probably go to comp.unix.shell.
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

Volume-Number: Volume 22, Number 90

From [e-mail]  Thu Jan 31 18:57:36 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20857; Thu, 31 Jan 91 18:57:36 -0500
Posted-Date: 31 Jan 91 10:05:36 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 31 Jan 91 10:05:36 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail] (michael gersten) writes:
> May I humbly ask what was wrong with vfork?

Yup.  I'll humbly try to answer.
>
> As I understand it, vfork's semantics was a virtual fork--
> conceptually two execution threads would return from the call,
> and they may or may not be sharing data space--any program
> that relied on one or the other was by definition broken.

The problem -- one problem -- is in coming up with a ``portable''
definition of ``data space''.  On what we currently assume to be
``vanilla flavour'' architectures such as that of the 68000 which you
cite, it's fairly obvious.  But on others, it's not.  What about
registers?  Are they data space?  No?  Even on architectures with
register windows which may or may not map onto main memory addresses?
Bear in mind that such exotica are not so exotic any more: RISCs use
them widely.

It seems that any definition which is safe on all architectures is
liable to constrain what one may do between [qv]fork() and exec() so
greatly that it turns out to be better to define a combined spwan()
function.  This would make it less likely that the POSIX standards would
contain explicit or implicit assumptions about the architecture of the
hardware on which a conforming implementation runs.  While this might be
nice for aging architectures such as that of (say) the Unisys 1100
series, more importantly, it would not constrain architectural
advances of the future needlessly to conform to the nineteen
seventies' ideas of what was a ``clean machine'' in order to be able
efficiently to implement POSIX interfaces.

> Now, why was it removed? What is wrong with it?

-- see also comp.std.unix Volume 22, Number 69.
--
Dominic Dunlop

Volume-Number: Volume 22, Number 93

From [e-mail]  Thu Jan 31 18:57:43 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20879; Thu, 31 Jan 91 18:57:43 -0500
Posted-Date: 31 Jan 91 19:08:05 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Shell standardization (for c.std.unix)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 31 Jan 91 19:08:05 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>On some older SysV-based systems I've used, scripts that start with the '#'
>character are interpreted as csh scripts no matter what follows the '#'.

That was a bug in porting a pre-#! era csh feature.  On UNIX System V,
more often than not Bourne shell scripts begin with '#'.  Therefore it
was unwise to leave that vestigial feature in csh when porting it to
such an environment.

The basic answer is that there is no truly portable solution, other
than writing Bourne shell scripts starting with non-# that invoke
whatever other command is actually wanted, using some sort of path
search to find it.

Of course Plan 9's user-mounted appendable directories makes this easier..

Volume-Number: Volume 22, Number 95

From [e-mail]  Thu Jan 31 18:59:45 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21397; Thu, 31 Jan 91 18:59:45 -0500
Posted-Date: 1 Feb 91 18:00:00 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: call for volunteer moderator
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 1 Feb 91 18:00:00 GMT
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

Since the end of October 1990, there has been no funding for moderation
of the newsgroup comp.std.unix and its associated mailing list
[e-mail].  Since that time, I have sought such funding
from several user groups, the IEEE Computer Society (IEEE/CS), the
IEEE/CS Technical Committee on Operating Systems Standards Subcommittee
(TCOS-SS), and various private companies.  No funding is forthcoming.
As I remarked three months ago, I cannot afford to moderate the newsgroup
as a volunteer.  I have solicited volunteers, but no one has thus far
come forward.

So, this is a final call for a volunteer moderator, responses to be
received at [e-mail] by 15 February 1991.

If there is:
* one volunteer, that one will become the new moderator;
* more than one volunteer, the last one to apply will conduct a vote
    by USENET rules to determine who becomes the moderator;
* no volunteer, the newsgroup will become unmoderated.

I will not discriminate among applicants:  all are equally valid,
regardless of qualifications.

Arrangements for archives and interconnection between the newsgroup
and the mailing list will have to be worked out by the new moderator,
if any.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 22, Number 91

From [e-mail]  Thu Jan 31 19:02:42 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22138; Thu, 31 Jan 91 19:02:42 -0500
Posted-Date: 31 Jan 91 11:51:34 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: IEEE TCOS, New Orleans, January 1991: EurOpen IR's report
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 31 Jan 91 11:51:34 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)


            Standards Column to be Published in
              EurOpen Newsletter, Spring 1991

              Dominic Dunlop -- [e-mail]

                  The Standard Answer Ltd.


     Production of this article was funded by EurOpen,
     the European Forum for Open Systems (formerly
     EUUG).  Copyright EurOpen, 1991.


For the past couple of years, these columns have discussed
events and developments in the POSIX-related activities of
the International Organization for Standardization (ISO).
This time, I'm going to look at a lower -- but arguably
equally important -- level in the standards development
process: the Institute of Electrical and Electronic
Engineers' Computer Society Technical Committee on Operating
Systems Standards Subcommittee.  Let's just call it
IEEE-CS TCOS SS, or, better still, TCOS.

Last October, EurOpen agreed to provide funding for an
institutional representative who would attend the quarterly
meetings of TCOS, and provide a means of routing input from
European users of open systems into the bewilderingly large
variety of POSIX standards being developed by working groups
under TCOS.  I am that representative, and, since I'm
spending your money, I'd better tell you what is going on,
why it's important, and how you can help me out.

        POSIX_Development_--_Top_Down_or_Bottom_Up?

I've referred to the IEEE in my reports on ISO matters,
since it is the IEEE which actually develops the standards.
The IEEE routes its documents to ISO via ANSI, the American
National Standards Institute.  Translating this into ISO-
speak, ISO has designated ANSI, its U.S.  member body, as
the development agency for the POSIX standards.  ANSI, in
turn, has delegated the work to the IEEE, an accredited body
which it considers competent to create operating system
standards through a consensus process which allows all
interested parties to comment.

This makes the process of standards development look as
though it proceeds from the top down: somebody associated
with ISO decides that the time is right for a POSIX
standard, identifies a means of getting the job done, and
controls the process in an orderly, structured manner.

Life is not like that.  No matter how much those who work at
the ISO level would like to believe that they are, and
always have been, in the driving seat, the movement towards
POSIX started from the bottom and drifted up.  It started in











                           - 2 -



the early nineteen-eighties with /usr/group, a U.S.-based
organization of suppliers and commercial users of open
systems, now known as UniForum.  This group created The 1984
/usr/group Standard, a minimal definition of an operating
system interface corresponding broadly to the unprivileged
services offered by AT&T's UNIX System III, together with
selections from the Kernighan & Ritchie C language library.
Slim but seminal, this document was passed into the IEEE
(specifically, to the newly-formed TCOS) to provide the
foundation of the POSIX standards.  It also gave important
input to ANSI in the creation of a standard for the C
language.

Despite the fact that neither the IEEE nor ANSI puts any
nationality requirement on the individuals (in the case of
the IEEE) or the organizations (for ANSI) participating in
the creation of their standards, both POSIX and C initially
developed in the U.S. with little international input.  The
costs of travel and of assigning English-speaking technical
experts to the task was (and is) one disincentive; another
is the feeling, particularly in Europe, that standards
activity should begin at home, rather than in the U.S.

By 1987, the international demand for standards for POSIX
and C was obvious, and it was natural that ISO should get
involved.  To be pedantic -- and the standards world is
nothing if not pedantic -- it was natural that Joint
Technical Committee 1 (JTC1) of ISO and the International
Electrotechnical Commission (IEC) should get involved.
(JTC1 had been formed in the mid-eighties to end wrangles
between ISO and the IEC over the right to create standards
for information technology.)  It was also natural that the
project for the international standardization of the C
language should be handled by JTC1's Subcommittee (SC) 22,
which is concerned with programming languages.  SC22 Working
Group (WG) 14 was duly set up to do the job.

It was less natural for POSIX to be assigned to WG15,
another new group under SC22.  An operating system
interface, after all, is hardly a programming language.
Nevertheless, after an attempt to set up a new SC to handle
system interfaces had failed for political reasons, SC22
picked up the work1.  Both WG14 and WG15 appointed ANSI as


__________

 1. SC21, which is responsible for the higher layers of OSI,
    for SQL and for office document architectures and the
    like, might have been a candidate, but, after a false
    start with OSCRL (see my last column), was not











                           - 3 -



the development agency for their respective standards,
leaving us with today's situation.

At this point, I shall have to stop discussing C
standardization, as it is not a field in which I am active2.
But I can tell you more than you probably want to know about
the activities of IEEE TCOS, which is at the work-face of
POSIX development.

                     POSIX_in_the_IEEE

When TCOS was set up in 1985, it had just one IEEE standards
creation project under its control -- project 1003, known as
P1003.  (Other well-known IEEE standards projects are 754
for floating point formats, and 802 for local-area
networks.)  P1003 quickly split into two sub-projects:
P1003.1 for the operating system interface, and P1003.2 for
the shell and tools.  (Recently, these have come to be known
as POSIX.1 and POSIX.2.)  A working group was associated
with each.  The working groups were named after the
projects: 1003.1 and 1003.2.

This splitting has continued, with around 30 projects
currently active.  Whenever a possible new POSIX-related
standards activity is identified, its promoters can draw up
a Project Authorization Request (PAR), and submit it to the
Sponsor Executive Committee (SEC) of TCOS3.  If approved
(sponsored in IEEE terminology), and subsequently rubber-
stamped by the  IEEE Computer Society's Standards Activities
Board (SAB), a new project is created.  Most become sub-
projects of the original 1003 project; some initiate new
projects, such as P1201 on windowing environments.

If the subject of a new activity is closely associated with
the interests of an existing working group, it is assigned
to that group; if it is not, a new working group is set up.
This means that there are fewer working groups than


____________________________________________________________

    interested.

 2. Although I can tell you that ISO 9899, the C standard,
    went to the printers late in 1990, but, at the time of
    writing, has yet to emerge.  It is functionally
    identical to the U.S. standard, ANSI X3.159-1989.

 3. PARs can also be used to request changes to the goals
    and terms of reference of existing projects.












                           - 4 -



projects.  As an example, the 1003.0 working group is
concerned solely with the 1003.0 guide to the POSIX
environment, but the 1003.1 working group now handles
1003.1, the operating system interface; 1003.16, C language
bindings to operating system services; and 1003.18, a
profile for a "traditional" POSIX-based system.

Once a working group has been formed, its job is to draft
standards, making sure that they meet the needs of both
suppliers and users of information technology.  This is done
through a somewhat baroque balloting process:

   - Associated with each working group is a balloting
     group.  The balloting group is typically formed shortly
     before the circulation of the first complete draft of
     the first standard developed by the working group.

   - Balloting groups are drawn from the membership of a
     balloting pool.  The pool has three types of member:
     individual members of the IEEE who have specifically
     applied to join the pool4; institutional
     representatives (IRs) accepted by the IEEE-CS SAB (see
     below); and national heads of delegation to the ISO
     POSIX working group.

   - All members of the balloting pool are sent notice of
     the formation of each new balloting group.  Those who
     respond become members of the group, subject to
     considerations of maintaining a balance between user
     and supplier representatives.

   - Once a balloting group has been formed, it persists
     indefinitely with a static membership.  Only if there
     are problems in getting the required 75% response to
     ballots is the membership of a group reviewed.

   - It is almost never possible to join a balloting group
     after it has formed.

   - Individuals or organisations outside the balloting
     group can make objections to, or comments on, the
     content of draft standards, just as can balloting group
     members.  All objections from whatever source must be


__________

 4. The requirement for IEEE membership appears recently to
    have been dropped, although the rule book has yet to be
    amended.












                           - 5 -



     handled through a formal resolution process.  However,
     only members of the balloting group can vote for or
     against the acceptance of a draft (or indeed,
     completed) standard.

   - A draft is considered approved if it is accepted by 75%
     or more of those who vote either for it or against it5.

Simple, huh?  And I haven't even mentioned the appeals
procedure!

Membership of a balloting group is a considerable
responsibility:  following notice of a ballot, IEEE rules
give just 30 days to review a document which may run to
almost a thousand pages, and to return any comments or
objections to the ballot coordinator.  And unless over 75%
of the membership of the ballot group responds, the result
is held to be invalid.  When one considers that a document
is likely to go through a dozen drafts before it becomes an
approved standard, it is clear that balloters have to work
hard (even if not all of the drafts are balloted).
Recirculation ballots, initiated when changes are made to a
draft in response to an initial ballot, increase the work-
load further.

In order to make the task a little easier, TCOS has adopted
a procedure called a mock ballot to handle the early drafts
of a document.  These are similar to mock examinations: the
procedures are identical to the real thing, but it doesn't
matter so much if it is flunked.  In particular, no alarm
bells start ringing in the IEEE's offices if a 75% response
is not achieved.

           What_has_all_this_to_do_with_EurOpen?

EurOpen feels that it is important that the views of its
membership are represented in two forums.  Firstly, on the
SEC, which decides on the authorization of POSIX-related
projects and controls their development and coordination;
and secondly, in the balloting pool from which those who
vote on the content and acceptance of standards are drawn.




__________

 5. If more than 30% of those who return their ballots
    abstain, things get more complicated.  Let's not go into
    that.












                           - 6 -



The first objective has already been met:  I am happy to be
able to tell you that the SEC has unanimously accepted
EurOpen's request for me to become its institutional
representative6.  I join existing IRs from a number of user
groups and industry bodies:  the Open Software Foundation,
OSSWG (a group developing a real-time kernel for embedded
systems), SHARE (the IBM user group), UniForum, UNIX
International, USENIX and X/Open7.  (UniForum and USENIX
were particularly helpful in the preparation of EurOpen's
application.)

Gaining IR status in the balloting pool takes longer, as
EurOpen's request must be discussed by the SAB, but I hope
to be able to report in the Spring Newsletter that it has
been approved.

Luckily, this delay gives me a little breathing space to
make a request.  I need help from volunteers.  If you feel
competent to help EurOpen's newly-formed Standards
Activities Management Group (SAMG) in formulating responses
to IEEE POSIX ballots, please contact me at the mail address
at the head of this article8.  In particular, could experts
on secure operating systems please get in touch, as the
working group concerned with this aspect of POSIX, 1003.6,
is in the process of forming a balloting group.

I hope to see you at the standards birds-of-a-feather
session at EurOpen's spring conference in Tromso, where
members of the SAMG will be reporting on the latest
developments in the  Europe, the U.S.A. and the world at
large.








__________

 6. Actually, the acceptance was "by acclamation", which is
    even better.

 7. The Free Software Foundation (FSF) is likely to join the
    list later this year.

 8. The other members of the SAMG are Johan Helsingius
    ([e-mail]) and Henk Hesselink ([e-mail]).










--
Dominic Dunlop



Volume-Number: Volume 22, Number 92

From [e-mail]  Sat Feb  2 14:21:35 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25778; Sat, 2 Feb 91 14:21:35 -0500
Posted-Date: 1 Feb 91 02:18:25 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: twinsun![e-mail] (Paul Eggert)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Twin Sun, Inc
X-Submissions: [e-mail]
Date: 1 Feb 91 02:18:25 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Paul Eggert)

    ... any definition which is safe on all architectures is liable to
    constrain what one may do between [qv]fork() and exec() so greatly
    that it turns out to be better to define a combined spawn() function.

What's wrong with the following definition, which permits the usual actions
between fork() and exec()?  Isn't this definition easy to explain and support?

    vfork() acts like fork(), except:

    1.  Any variables that are common to both parent and child, and are
    changed by the child before it exits or execs, have undefined values in
    the parent when its vfork() returns.

    2.  The child may not call unsafe standard functions (these are
    nonreentrant; see Posix 1003.1-1988 section 3.3.1.3(3)(f)).

    3.  The child may not return from the function that called vfork(),
    either explicitly or via longjmp().

    4.  The program must #include <vfork.h>.

(2) follows from (1).  (4) is common practice, and gets around the exotic
architecture problem.  (2)'s phrase ``common to both parent and child'' lets
the child call reentrant functions, because their automatic variables do not
exist in the parent.

I don't much like vfork(), but it's common practice, it is much faster on many
hosts, and many widely distributed Unix programs use it.  By all means, let's
invent other primitives if they're needed, but why not first standardize the
primitives we already have?

Volume-Number: Volume 22, Number 96

From [e-mail]  Sat Feb  2 14:24:35 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26095; Sat, 2 Feb 91 14:24:35 -0500
Posted-Date: 1 Feb 91 15:08:31 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: Is there a standard prototype for `execvp'?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 1 Feb 91 15:08:31 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (Ron Guilmette) writes:

>It is somewhat dated now, but the only book I have about POSIX is
>copyright 1988.

The new version of POSIX.1, IEEE Std 1003.1-1990, came out last
December.  You can get it from the IEEE; their number is 1-800-678-IEEE,
and I think that the order number is SH13680.  It uses ANSI C prototypes.
execvp(), for example, is:

    int execvp(const char *file, char *const argv[]);

It also has quite a number of other "bug fixes".

>Reading that book, it seems that the POSIX committee didn't want to
>use ANSI C function prototypes for their specification of the C language
>binding because prototypes were too "new-fangled".  Specifically, they
>apparently choose not to express the binding in terms of prototypes because:

ANSI C "wasn't" when the 1988 version of POSIX was written.  There were
drafts of the C standard around, but it wasn't approved, and there was no
guarantee that it wouldn't change.  That was the main reason for staying
with the traditional syntax.

Volume-Number: Volume 22, Number 97

From [e-mail]  Sat Feb  2 14:32:23 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26906; Sat, 2 Feb 91 14:32:23 -0500
Posted-Date: 1 Feb 91 17:45:53 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Is there a standard prototype for `execvp'?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 1 Feb 91 17:45:53 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donn Terry)

>Submitted-by: [e-mail] (Ron Guilmette)

>Reading that book, it seems that the POSIX committee didn't want to
>use ANSI C function prototypes for their specification of the C language
>binding because prototypes were too "new-fangled".  Specifically, they
>apparently choose not to express the binding in terms of prototypes because:

>    "... the Working Group was aware that some vendors would wish
>    to implement POSIX in terms of a binding to an historical
>    variant of the C language..."

That was appropriate at the time.  The -1990 version uses ANSI C
prototypes (now that ANSI C is approved, and implementations are
available).

>In addition to avoiding prototypes, the POSIX folks also (apparently)
>decided to avoid the use of ANSI C type qualifiers (i.e. "const" and
>"volatile") in the C binding.

Avoided for the same reasons.

>Now even thought I don't really keep up on such things, I assume that
>some progress has been made since 1988.  Is there now also an ANSI C
>binding for POSIX?  If so, please tell me the exact name of *that*
>document so that I can go buy a copy.

Specifically IEEE Std. 1003.1-1990
a.k.a. ISO/IEC JTC-1 IS 9945-1:1990
(Available from IEEE at the same place you got your -1988 version.)

>For example, my intuition tells me that a "proper" prototype for `execvp'
>should look like:

>    extern int execvp (const char *, const char *const *);

The new standard has the declaration as:

    int execvp (const char *file, char *const argv[]);

It was generally agreed during balloting that what really was wanted
was "const char * const argv[]".  However, ANSI C disagrees: that's
a syntax error!

(There's a bunch of rationale about why the specific declaration was
chosen, I won't repeat it here, but the bottom line is that given
that you can't have both const's, this is the best choice remaining.)

Donn Terry
Speaking only for myself.

Volume-Number: Volume 22, Number 98

From [e-mail]  Sun Feb  3 12:55:08 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA09103; Sun, 3 Feb 91 12:55:08 -0500
Posted-Date: 3 Feb 91 05:30:06 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Kithrup Enterprises, Ltd.
X-Submissions: [e-mail]
Date: 3 Feb 91 05:30:06 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Paul Eggert) writes:
>What's wrong with the following definition, which permits the usual actions
>between fork() and exec()?  Isn't this definition easy to explain and support?
[stuff]

Because one of the few reasons I would like vfork() (or something similar)
is now missing:  the parent does not execute until the child has exit'ed or
exec'ed something.

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 99

From [e-mail]  Sun Feb  3 12:57:18 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA09305; Sun, 3 Feb 91 12:57:18 -0500
Posted-Date: 3 Feb 91 12:43:12 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Masataka Ohta)
Newsgroups: comp.std.unix
Subject: Re: qfork() (again)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Tokyo Institute of Technology
X-Submissions: [e-mail]
Date: 3 Feb 91 12:43:12 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Masataka Ohta)

In article <[e-mail]> [e-mail] writes:

>The problem -- one problem -- is in coming up with a ``portable''
>definition of ``data space''.

These are 'problems' (actually, not a problem) of C, not UNIX.

There is no problem about data space. C has clear and portable notion
of what is data space: register and memory. That's all.

It has very little to do with UNIX nor vfork().

>On what we currently assume to be
>``vanilla flavour'' architectures such as that of the 68000 which you
>cite, it's fairly obvious.  But on others, it's not.  What about
>registers?  Are they data space?  No?  Even on architectures with
>register windows which may or may not map onto main memory addresses?
>Bear in mind that such exotica are not so exotic any more: RISCs use
>them widely.

Clearly, on exotic architectures, a C (not UNIX) pointer may point
to a register. It may be an exotic feature of C. But, it never is a
problem of C nor UNIX nor vfork().

>It seems that any definition which is safe on all architectures is
>liable to constrain what one may do between [qv]fork() and exec() so
>greatly

No.

First, list every operations which is safe between fork() and exec()
*and* between BSD vfork() and exec().

Then, those are the safe operations of POSIX vfork() on *all* architectures.

>that it turns out to be better to define a combined spwan()
>function.

Most (perhaps, more than 90%) of cases where fork/exec is necessary
is covered by system(). spawn() is not necessary.

Rest are special cases, where combined spawn() can help very little
and separate [v]fork() and exec() is really necessary.

Is it a role of POSIX to define unnecessary and totaly alien functions
and badly modify UNIX?

Don't try to reinvent wheels.

                    Masataka Ohta

Volume-Number: Volume 22, Number 100

From [e-mail]  Sun Feb  3 12:59:17 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA09651; Sun, 3 Feb 91 12:59:17 -0500
Posted-Date: 3 Feb 91 12:54:51 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Masataka Ohta)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Tokyo Institute of Technology
X-Submissions: [e-mail]
Date: 3 Feb 91 12:54:51 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Masataka Ohta)

In article <[e-mail]>
    [e-mail] (Richard Tobin) writes:

>Of course, these programs don't usually change many variables, so a
>copy-on-write fork() won't need many pages in this case.  A c-o-w
>fork() with late allocation of pages could could be as robust as
>vfork() almost always by pre-allocating a few pages.

That is the case where COW fork() with late allocation of pages or
vfork() must be used.

>Surely the problem is when it's being used as a *real* fork(), and the
>program fails much later when it modifies one variable too many.

If fork() is used as a real fork(), it is very probable that it modifies
its data space many times.

The severe problem is that the program can not control the failure.
It immediately dies.

With non-COW fork() or COW fork() with immediate allocation of pages,
such a failure can be detected as error return value of fork()
and may be processed in a controlled fashion.

                    Masataka Ohta

Volume-Number: Volume 22, Number 101

From [e-mail]  Mon Feb  4 18:57:42 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06085; Mon, 4 Feb 91 18:57:42 -0500
Posted-Date: 4 Feb 91 14:50:55 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: IEEE TCOS, New Orleans, January 1991: EurOpen IR's report
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 4 Feb 91 14:50:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

Hal Jespersen adds the following to my report (Volume 22, Number 92):
>
>  4. The requirement for IEEE membership appears recently to
>     have been dropped, although the rule book has yet to be
>     amended.
>
This was an incorrect annoucement at the IEEE COmputer Society
Standards Coordinating Committee (SCC) meeting.  The Stds Board
disapproved this idea.
>
>    - Once a balloting group has been formed, it persists
>      indefinitely with a static membership.  Only if there
>      are problems in getting the required 75% response to
>      ballots is the membership of a group reviewed.
>
The 75% response rule is only for the first ballot.  During recirculations,
considerably less paper can flow.  And does.

(Recirculation ballots occur to check the acceptability of the amendments
which have been made to a draft standard as a result of the the
objections and comments received in a previous round of balloting.
While these amendments are generally intended to change negative votes
into positive, it is possible that they may have the reverse effect if
it turns out that balloters object strongly to some of the changes.
Recirculation ballots check that more, rather than less, consensus is
being achieved.)

--
Dominic Dunlop

Volume-Number: Volume 22, Number 102

From [e-mail]  Mon Feb  4 19:04:19 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07871; Mon, 4 Feb 91 19:04:19 -0500
Posted-Date: 4 Feb 91 16:32:06 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: OSF Research Institute
X-Submissions: [e-mail]
Date: 4 Feb 91 16:32:06 GMT
To: [e-mail]

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] writes:
> 2.Similarly, OSF/1 is "currently under development" but is having some
problems
>     getting off the ground.  I believe IBM has pulled out of the effort to
>     develop the operating system, in favour of AIX which works.  What are the
>     dates of:    1.the formation of OSF
>                  2.the development phase of the OSF/1 operating system
>                    (is it still under development, or  has it been abandoned
>                      completely after the pull out by Big Blue?)
>     What are the Unix roots of the OSF/1 operating system?  i.e. was it
>     developed from System V.2, or Mach from Carnegie Mellon U?

OSF/1 1.0 was released for general distribution on December 7 1990.
There are no problems that I know of that has prevented it getting off
the ground and I was one of the development team. In fact the project
slipped only 2 or 3 weeks from its original ship date which is pretty
impressive for a project of that magnitude I think.

At the general release announcement the sponsors endorsed OSF/1 and many
(including IBM) announced that they would be using OSF/1 as part of
their operating system technology. The final IBM product could well be
called AIX but that is their perogative and a marketing decision I would think.

To question 1, OSF, the company, was formed in May 1988. As I said,
OSF/1 has already shipped and your information about IBM is incorrect.

OSF/1, simplistically, is the integration of Mach 2.5 microkernel and
BSD 4.4 but there has been a significant contribution of technology from
various sources, IBM, Mentat, Secureware, Encore, to name a few (I
apologise to those I have ommited), and of course OSFs own development
group. There is a small amount of AT&T System V.2 code in the kernel but
not much and it is well isolated.

> 4.Is there a competition between System V.4 and OSF/1, in the sense that one
>     will be chosen as the ANSI standard Unix, or are they both sufficiently
>     conformant to current ANSI/POSIX standards, that this is not an issue:
>     that the competition is strictly in the marketplace?

As far as I am concerned there is no competition. Both systems support
the standard interfaces (POSIX, FIPS, XPG3, ANSI-C, etc) so with respect
to strictly conforming application portability the two systems should be
identical. Obviously there are other differences, for example in the
area of multiprocessor support, threads, dynamic configuration, etc but
I will stick my neck out and guess that neither system will be "chosen"
by any standards body as the one and only true system.

The current status is that OSF/1 1.1 is already under development and
likely to be available sometime in the next 12 months or so, I don't
know the exact ship date. The system today has already been ported to
more that 8 different architectures, including a MIPS R2000, National
Semi 32532, Motorola 68030, Intel 80386 and I860, Fairchild clipper and
more, I forget them all.

DISCLAIMER: This is not an official statement from OSF.

  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                       uunet!gr.osf.org!sp

Volume-Number: Volume 22, Number 103

From [e-mail]  Mon Feb  4 19:10:35 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09252; Mon, 4 Feb 91 19:10:35 -0500
Posted-Date: 4 Feb 91 16:01:20 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Peter Salus)
Newsgroups: comp.std.unix
Subject: Re: call for volunteer moderator
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: The World @ Software Tool & Die
X-Submissions: [e-mail]
Date: 4 Feb 91 16:01:20 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Salus)

In article <[e-mail]> [e-mail] writes:
>Submitted-by: [e-mail] (John S. Quarterman)
>
>Since the end of October 1990, there has been no funding for moderation
>of the newsgroup comp.std.unix and its associated mailing list
>[e-mail].  Since that time, I have sought such funding
>from several user groups, the IEEE Computer Society (IEEE/CS), the
>IEEE/CS Technical Committee on Operating Systems Standards Subcommittee
>(TCOS-SS), and various private companies.  No funding is forthcoming.
>As I remarked three months ago, I cannot afford to moderate the newsgroup
>as a volunteer.  I have solicited volunteers, but no one has thus far
>come forward.
>
>So, this is a final call for a volunteer moderator, responses to be
>received at [e-mail] by 15 February 1991.
>

As .stc.c and .std.internat are unmoderated and have not
gone berzerk, could someone (perhaps jsq) explain why .std.unix
needs to be moderated?

Peter

--
The difference between practice and theory in practice is always
greater than the difference between practice and theory in theory.

Volume-Number: Volume 22, Number 104

From [e-mail]  Mon Feb  4 19:19:00 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11068; Mon, 4 Feb 91 19:19:00 -0500
Posted-Date: 4 Feb 91 19:39:21 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Is there a standard prototype for `execvp'?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U of Toronto Zoology
X-Submissions: [e-mail]
Date: 4 Feb 91 19:39:21 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Donn Terry) writes:
>    int execvp (const char *file, char *const argv[]);
>
>It was generally agreed during balloting that what really was wanted
>was "const char * const argv[]".  However, ANSI C disagrees: that's
>a syntax error!

This puzzled me a bit, since that is *not* a syntax error, but a bit of
private correspondence with Donn cleared it up.  The problem is not that
the declaration is illegal, but that `char *[]' and `const char *const []'
are not assignment-compatible -- the "inner" const does not magically get
ignored like the "outer" one -- so this would break backward compatibility.
--
"Maybe we should tell the truth?"      | Henry Spencer at U of Toronto Zoology
"Surely we aren't that desperate yet." |  [e-mail]   utzoo!henry

Volume-Number: Volume 22, Number 106

From [e-mail]  Mon Feb  4 19:23:19 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12151; Mon, 4 Feb 91 19:23:19 -0500
Posted-Date: 4 Feb 91 16:45:17 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: spawn() wars... please... not again...
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 4 Feb 91 16:45:17 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

Look, I know you don't like spawn(). But in a lot of environments... INCLUDING
ONES THAT ARE OTHERWISE QUITE CAPABLE OF SUPPORTING A POSIX ABI... it is *not*
possible to do a safe and efficient implementation of fork(). Leave in the
fork() call, but allow a more efficient (and, let's face it, easier to
understand) alternative: spawn().

In article <[e-mail]> [e-mail] (Masataka Ohta) writes:
> First, list every operations which is safe between fork() and exec()
> *and* between BSD vfork() and exec().

> Then, those are the safe operations of POSIX vfork() on *all* architectures.

No. Those are the safe operations between fork() and exec() on UNIX.

POSIX looks like it's going to comprise far more than UNIX.

Let's say you define vfork() as "set a flag that all posix calls that deal
with uid, signals, files, etc... look at, so they just write a "script" of
actions to take on behalf of the new process".

Then, you define "exec" as "look at the script, if there, and cons up an
efficient system call on the underlying O/S (VMS, for example) to satisfy
it".

> Most (perhaps, more than 90%) of cases where fork/exec is necessary
> is covered by system(). spawn() is not necessary.

    No, system() and popen() can not, ever, let you pass a set of
    arguments to a program without diddling by the shell. When you
    have no way of knowing whether that shell will be sh, csh, ksh,
    or even rc what can you do to protect yourself?

    Who knows, I can easily imagine DEC setting things up so a user
    could set his shell to DCL and hose *everything* up.

    Using system() in programs like (for example) uucp, mail handlers,
    and so on is a security hole you can drive a truck through. There
    are lots of systems where you can use this to get pretty much *any*
    file on a neighbor's machine.
--
Peter da Silva.  `-_-'  [e-mail]
[phone].  'U`  "Have you hugged your wolf today?"

Volume-Number: Volume 22, Number 105

From [e-mail]  Tue Feb  5 15:14:55 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25369; Tue, 5 Feb 91 15:14:55 -0500
Posted-Date: 4 Feb 91 11:50:07 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Chuck.Phillips)
Newsgroups: comp.std.unix
Subject: "#!" magic number  (was: Shell standardization)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
X-Submissions: [e-mail]
Date: 4 Feb 91 11:50:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck.Phillips)

>>>>> On 22 Jan 91 21:28:49 GMT, [e-mail] (Guy Harris) said:

Guy> I don't strongly care where it's done (although I *do* prefer having
Guy> "execl()" AND "execv()" capable of running scripts, even if it's done by
Guy> having them be wrappers around kernel traps with the wrappers checking
Guy> for the "#!" line if they get ENOEXEC), but it *would* be nice if the
Guy> system didn't inappropriately try to run files that happened to have
Guy> execute permissions as scripts if, in fact, they aren't scripts.

Essentially, "#!" becomes a magic number.  I would also prefer this be in
the kernal.

Invitation for discussion: If the path after the "#!" doesn't begin with
"/", "./" or "../", should PATH be searched for the execuatble?  If so, how
best could this be implemented?

The reason I bring this up is in SVr4 (OSF/1?), there have been changes in
the directory hierarchy and commands are not necessarily where they've
historically been.  Of course, all scripts that are part of the OS can (and
should!) contain absolute path names.  It would be nice for application
developers to be able to write hierarchy independent scripts.  Even nicer
would be for applications developers to be able to write their own
interpreters without caring where the user installs the interpreter (as
long as the interpreter's directory is in PATH).
--
Chuck Phillips  MS440
NCR Microelectronics             chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO.  80525           ...uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 22, Number 107

From [e-mail]  Tue Feb  5 15:30:53 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00016; Tue, 5 Feb 91 15:30:53 -0500
Posted-Date: 5 Feb 91 19:31:34 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (Dick Dunn)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Interactive Systems Corporation, Boulder, CO
X-Submissions: [e-mail]
Date: 5 Feb 91 19:31:34 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dick Dunn)

[e-mail] (Simon Patience) writes, among explanations of OSF
history and status, that:

> OSF/1, simplistically, is the integration of Mach 2.5 microkernel and
> BSD 4.4...

This is incorrect on two counts.  First, Mach 2.5 is not a "microkernel"
implementation--it still contains conventional kernel functions.  The
"microkernel" version of Mach is 3.0.  (However, it *is* correct that OSF/1
is based on the non-"micro"kernel 2.5.)  Second, OSF/1 could not have
integrated BSD 4.4, because BSD 4.4 is not done yet--at least not accor-
ding to the folks at Berkeley!  Probably what is meant here is that OSF/1
has incorporated some of the Berkeley "Reno" code, Reno being the name
attached to a pre-4.4 release of code intended for developers who want to
try it out and shake out the bugs.
--
Dick Dunn     [e-mail] -or- ico!rcd       Boulder, CO   [phone]
   ...Don't lend your hand to raise no flag atop no ship of fools.



Volume-Number: Volume 22, Number 108

From [e-mail]  Tue Feb  5 15:53:11 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06891; Tue, 5 Feb 91 15:53:11 -0500
Posted-Date: 5 Feb 91 20:51:33 GMT
Received: by cs.utexas.edu (5.64/1.93)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: call for volunteer moderator
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 5 Feb 91 20:51:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

The most numerous kind of response so far to my call for a volunteer
moderator has been from people saying they might volunteer if they
knew more.  Sorry, that's not what I asked for.  I asked for volunteers,
not potential volunteers.  I did not say I would train a new moderator.
Nor did I offer to explain how USENET works.  Nonetheless, the last one
to volunteer by the deadline gets to handle voting according to USENET
rules as to who (if anyone) becomes the moderator.  If you don't know
what the rules are, it would be good to find out before volunteering
(I don't know the details myself, so it won't do any good to ask me.)

To do a reasonable job of moderation for this newsgroup has taken me a
measured average of about 10 hours a month.  It might take you more or
less hours.

I have appended below a copy of the editorial policy statement that
appeared at the beginning of the current volume of comp.std.unix.
However, I can make no recommendations as to what the editorial policies
of any new moderator should be.

Once again, volunteers should send a message to [e-mail]
by 15 February 1991.  The order such messages are *received* at that address
determines who (the last one to volunteer) gets to run the vote if there is
more than one volunteer.  Only messages that say that the sender definitely
volunteers to be moderator count for this ordering.


From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Policy
Reply-To: [e-mail]

This is a policy statement for comp.std.unix.

This is Volume 22 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Topic.

The USENET newsgroup comp.std.unix, also known as the mailing list
[e-mail], is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

Other related standards bodies and subjects include but are not limited to
    IEEE 1201 and IEEE 1238,
    ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
    the U.S. and other Technical Advisory Groups (TAGs) to WG15,
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba,
    and the USENIX Standards Watchdog Committee.

Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is John S. Quarterman.

Disclaimer.

Postings 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.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


Postings.

Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:

        DNS address            UUCP source route
Submissions    [e-mail]        uunet!std-unix
Comments    [e-mail]    uunet!std-unix-request

The hostname cs.utexas.edu may be used in place of uunet.uu.net or uunet.
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.

The mailing list is distributed on the Internet, UUCP, and elsewhere.
There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
Please send submissions from those networks to [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

If you have access to USENET, it is better (more efficient, cheaper,
less effort for me to manage) to subscribe to the newsgroup comp.std.unix
than to the mailing list.  Submissions should still go to the above
addresses, although many (perhaps most) USENET hosts will forward
attempts to post directly to the newsgroup to the moderator.

Posted articles may originate from uunet.uu.net, longway.tic.com, tic.com,
cs.utexas.edu, or usenix.org.  There are also occasional guest moderators,
who may post from still other machines.  Guest moderators are announced
in advance by the regular moderator.

Archives.

Archives for comp.std.unix or [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to uunet.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/comp.std.unix/archive
or
        ~ftp/comp.std.unix/volume.22
The previous volume may be retrieved as
        ~ftp/comp.std.unix/volume.21.Z
and so forth for more ancient volumes.

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell.

The output of "cd ~ftp/comp.std.unix; ls -l" is in
        ~ftp/comp.std.unix/list
and the output of "cd ~ftp/comp.std.unix; ls -l *" is in
        ~ftp/comp.std.unix/longlist

For further details, retrieve the file
        ~ftp/comp.std.unix/README


General submission acceptance policy.

Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days.  If you wait
and still don't see anything, try sending again.

I usually post about 90% of all submissions.  However, as moderator,
I retain the right to reject submissions.  If a submission does not
appear relevant to comp.std.unix, it is sent back to the submittor with
a note saying why it is not appropriate.  Usually this is because it
just doesn't fit the topic of the newsgroup, in which case I suggest
another newsgroup.  Sometimes it is because someone else has already
given the same answer to a question, in which case I ask if the
submittor really wants it posted.  Occasionally I suggest editing that
would make an article more appropriate to the newsgroup.

Very occasionally I reject an article outright:  this is almost always
because it contains ad hominem attacks, which are never permitted
in this technical newsgroup.  There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.

Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.

Crosspostings are discouraged.  Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix.  This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.



Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of three types:  headers and trailers; comments; and typographical.

Headers and trailers

Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
    either hosta!hostb!host!user or, preferably, user@domain.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.

The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide.  If it's not of worldwide interest, it doesn't belong in
comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest.  If a submission arrives with a
Distribution:  line, such as na or us, I delete that line.

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.

Also, signatures that are excessively long may be truncated.



Comments

Comments by the moderator are sometimes added to clarify obscure
issues.  These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
appear that are written by the moderator:  these always end with
a signature that includes the words ``moderator, comp.std.unix.''

Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].

Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].

Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.

Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possesive or
``its'' as a contraction of ``it is'' are corrected.

Excess white space is deleted.

Lines longer than 80 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



Common kinds of postings.

There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals.  Here are three of the most common.

Calendar of UNIX-Related Events

Susanne W. Smith <[e-mail]> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <[e-mail]> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The first three are posted to
    comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.

These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS.  Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is Jeffrey
S. Haemer <[e-mail]>.  Reports on other committees, such as X3J11,
are also included when available.  These reports are published in
comp.std.unix/[e-mail] and ;login:  The Newsletter of the
USENIX Association.  They are also available for publication elsewhere.

EUUG/USENIX ISO Monitor Project

The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee.  This observer, Dominic Dunlop <[e-mail]>,
writes a report after each WG15 meeting, of which there are usually
two a year.  These reports are published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix.  They are also available for
publication elsewhere.

Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on uunet.uu.net.  Retrieve ~ftp/comp.std.unix/README for
details.

John S. Quarterman, moderator, comp.std.unix and [e-mail].


Volume-Number: Volume 22, Number 109

From [e-mail]  Wed Feb  6 14:28:56 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06588; Wed, 6 Feb 91 14:28:56 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Report on IEEE/CS TCOS-SS SEC
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Texas Internet Consulting
X-Submissions: [e-mail]
Date: 6 Feb 91 19:26:43 GMT
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

            Report on IEEE/CS TCOS-SS SEC meeting 16-18 October 1990 in
                                    Seattle, WA.

                                  1 November 1990

                          John S. Quarterman <[e-mail]>

                             Texas Internet Consulting

       IEEE/CS TCOS-SS SEC

       1.  What's an SEC?

       The IEEE Computer Society (IEEE/CS) has been delegated authority by
       IEEE for standards involving operating systems, and IEEE was in turn
       delegated authority by ANSI, which is the U.S. national standards body
       that holds formal representation to international standards bodies
       such as ISO.

       Committees and Sponsors

       Every IEEE/CS standards committee must have a sponsoring body.  All of
       the committees that met in Seattle in October are sponsored by the
       IEEE/CS Technical Committee on Operating Systems, Standards
       Subcommittee (IEEE/CS TCOS-SS).  They (IEEE 1003.x, 1201.y, 1224,
       1237, and 1238) are thus sometimes refered to as the TCOS standards
       committees.  These include the POSIX committees, but the term POSIX
       properly applies only to the IEEE 1003.x committees, and to the
       ISO/IEC JTC1 SC22 WG15 committee that deals with the same topics and
       drafts in their 9945 documents, but not to the other TCOS committees.

       If I've counted right, TCOS now sponsors 30 projects in 20 standards
       committees.

       SEC Composition

       Yes, but what's an SEC?  The Sponsor Executive Committee of IEEE/CS
       TCOS-SS, whose purpose is to oversee standards projects sponsored by
       TCOS.  The SEC is composed of the chairs of all the TCOS commitees,
       plus officers, e.g., Jim Isaak, Chair, Shane McCarron, Secretary, and
       various Vice-Chairs for specific subjects, many of whom are chairs of
       subcommittees:

       __________

         * UNIXTM is a Registered Trademark of UNIX System Laboratories in
           the United States and other countries.

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 2 -

            Vice-Chair       Area
            __________________________________
            Hal Jespersen    Technical Editing

            Ralph Barker     Coordination
            Robert Bismuth   Interpretations
            Dave Dodge       Logistics
            Lorraine Kevra   Balloting

       There are also steering committees for certain areas:

            ____________________________________
            Roger Martin   Conformance Testing
            Tim Baker      Distribution Services

       All the Institutional Representatives (IRs) to TCOS are also SEC
       members.  The IRs at the time of the October SEC meeting were:

            IR                   Organization
            _______________________________________________
            Ralph Barker         UniForum
            John S. Quarterman   USENIX
            Martin Kirk          X/Open
            Fritz Shultz         Open Software Foundation
            Shane McCarron       UNIX International
            ?                    SHARE (the IBM user group)
            ?                    Free Software Foundation
            ?                    ? (the Navy users group)

       The last two were approved at the October meeting.  There are two
       functions of an IR, which can be split: participating in SEC meetings
       and activities; and participating in ballotting groups, where the IRs
       ballot for their institutions, unlike all other ballotters, who vote
       as individuals.

       SEC Functions

       The SEC decides its own membership, either by electing officers, or by
       accepting new IRs, or by approving Project Authorization Requests
       (PARs) for new commitees.  Chairs of standards committees are
       appointed by TCOS-SS (i.e., normally by the TCOS-SS Chair, who is also
       the SEC Chair) and approved by their working groups.  In practice such
       a chair is normally named in the PAR that the SEC accepts to establish
       the committee.  The SEC can also abolish committees (see below), and
       it can establish rules for its own activities, such as for acceptance
       of PARs (see below).

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 3 -

       2.  Language Independence

       IEEE Std. 1003.1-1988, the original POSIX standard, is written in
       terms of the C Programming Language.  It makes some attempt to address
       the issue of multiple programming languages by distinguishing between
       Common Usage C and Standard C, and by definitions of conformance and
       compliance that are not tied to a specific language (you can have a
       POSIX system that doesn't have any language translator at all).
       Nonetheless, all the interfaces of 1003.1 are defined in terms of C.

       WG15 and LI

       WG15 has made it clear all along that language-specific standards are
       not acceptable to the ISO process.  The POSIX committees have accepted
       that judgment in principle, but not a single POSIX committee has
       produced a language independent (LI) document.  This is a problem not
       only for those committees such as 1003.2 and 1003.4 that are working
       on base documents, but also for those that are working on language
       bindings, such as the 1003.5 Ada committee and the 1003.9 Fortran
       committees.  Should the language binding committees attempt to produce
       ``thin'' documents that just refer to a language independent base
       document, or should they produce ``thick'' documents that specify the
       language-independent interface as well as the language binding?  It's
       hard to make thin language documents without existing language-
       independent base documents.  This is a good reason for LI, independent
       of what WG15 wants.  In fairness, it must be pointed out that at least
       1003.4 and 1003.1 are already doing substantial work on language
       independence.

       The LI issue came to a head at the June 1990 Paris WG15 meeting, which
       was the most recent one before the Seattle TCOS committee meetings.
       As related in Dominic Dunlop's ISO Monitor report, WG15 refused to
       accept the IEEE 1003.4 document (and several others) for consideration
       as an International Standard because it was not language independent.
       Since 1003.4, in particular, is already balloting, this left the SEC
       between a rock (WG15) and a hard place (getting its own committees to
       implement LI).  See also Paul Rabin's October posting on this subject.

       LI Resolutions

       An SEC subcommittee to examine the LI issue reported back a motion to
       require all TCOS committees to incorporate an LI part before ballot
       approval.  (There were actually several overlapping and sequential
       motions, each of which was savagely amended by the SEC, but let's keep
       such gore out of this report.) The LI notion was not happily received
       by some of the SEC members, particularly not by 1003.2.

       Various people queried whether such a requirement could be established
       without a separate PAR for each affected committee, in order to
       confirm an LI document for each one.  It was pointed out that the
       resolution specified an LI part, not a separate document, and thus no

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 4 -

       new PARs would be needed.  It was questioned whether such a
       requirement could be imposed on a standard already in balloting, since
       changes to such documents can only be made in response to the
       balloting process.  The SEC Chair pointed out that balloting changes
       could be made not only in response to objections, but also to
       balloting comments, and the resolution would appear as a comment.  (I
       don't believe anyone mentioned it specifically, but a document
       approved by its balloting group still has to be approved by the
       IEEE/CS Standards Activities Board, which is unlikely to approve
       anything not recommended by the IEEE/CS TCOS-SS SEC.) It was pointed
       out that whenever new conditions had been imposed on a standard in
       balloting (such as for test assertions), balloting had been delayed up
       to a year.  Several chairs made it clear that their committees didn't
       want to do this work, or at least didn't want it imposed on them by
       the SEC in this manner, especially considering that the gist of the
       new proposal had already been accepted by the SEC as a guideline in a
       previous meeting.

       An amendment was moved and seconded to make the LI rules applicable
       only to those standards that start balloting after 18 October 1990
       (the date of the meeting in process), thus excluding 1003.2 and
       1003.4.  This even though 1003.4 has apparently already done much of
       the LI work, and 1003.2 is apparently working on it.  The amendment
       was passed, and the base motion was passed as amended.

       But what about WG15?

       There was, nonetheless, some confidence that WG15 might alter its
       stand on the acceptance of, e.g., the 1003.4 document.  The SEC also
       approved a request from the U.S. TAG to forward specific drafts of
       five TCOS standards documents to WG15 when said drafts were available.
       We'll know soon whether WG15 will accept any of them, since the next
       WG15 meeting was the week after the TCOS meetings, and also in Seattle
       (well, Orcas Island).  Stay tuned for Dominic Dunlop's WG15 ISO
       Monitor Report and Susanne Smith's U.S. TAG snitch report.

       3.  It's dead, Jim

       The SEC did something that has never been done before in its history,
       and perhaps never in the history of IEEE standards activities.  It
       abolished a standards committee.

       Fragmentation and dissolution

       Several meetings back, IEEE 1003.8 fragmented into several committees
       to discuss specific subjects related to networking (excuse me:
       Distribution Services; TCOS does operating system interfaces, not
       networking).  Some of these, such as the 1003.12 Protocol Independent
       Interface (PII) committee and the current 1003.8 Transparent File
       Access (TFA) committee, are addressing topics clearly related to

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 5 -

       operating system interfaces and prior art, e.g., XTI and sockets for
       1003.12, and NFS, RFS, and AFS for 1003.8.  Others include IEEE
       1003.ns for Name Space/Directory Services (NS/DS) IEEE 1224 for
       Message Handling Services, and IEEE 1238 for OSI Application
       Portability Interfaces (OSI APIs).  But IEEE 1237 was about remote
       procedure call (RPC).  It was working in an area already being
       addressed by another standards committee, in this case, the ANSI X3
       T3.5 RPC Rapporteur Group.  1237 was also sparsely attended, and chose
       to meet with X3 T3.5 in the summer instead of with the other TCOS
       committees in Danvers in July.

       The 1237 committee proposed its own dissolution.  Specifically, it
       proposed that its chair, Ken Hobday, be thanked for his activities and
       appointed SEC Institutional Representative to the Rapporteur Group.
       The general idea drew little resistance, but there was a motion to
       amend by tying the dissolution of 1237 to the acceptance of its work
       by the X3 T3.5 RPC Rapporteur Group.  When it was made clear (by
       someone speaking for the 1237 chair, who was not present), that the
       1237 members had no intention of meeting again, regardless of what the
       SEC did, the motion to amend failed and the original motion passed.

       The Bones of the SEC

       ``It's dead, Jim,'' remarked Parliamentarian Jason Zions to Chair Jim
       Isaak, and to the great satisfaction of all concerned.

       4.  Robert's Rules

       When the number of TCOS committees grew to its current double dozen,
       SEC meetings became rather unweildy.  They seemed to last for days.
       Er, meetings actually do last for days (usually Tuesday and Thursday
       morning or evening), but a single day seemed like several.
       Fortunately, a parliamentarian came grunting out of Silicon Valley
       clutching a copy of Robert's Rules of Order.  We do all appreciate
       Jason Zions' efforts to organize the meetings, and they now only last
       for days.  We do get some interesting artifacts, though.

       A motion was made on an important topic.  Many thought that action
       should be taken immediately, but others thought the time and the
       motion weren't ripe.  So a motion was made to postpone discussion
       until January.  Jason confirmed that postponement was debatable, so
       the mover withdrew that motion and made a motion to table, which is
       not debatable.  Someone else made a motion to suspend the rule about
       motions to table not being debatable.  Just before the impending vote
       on this third-level-deep motion, the Chair pointed out that its mover
       wasn't a member of the SEC.  Others pointed out that the mover of the
       motion to table wasn't, either, because we had just abolished his
       committee.  The Chair opined that that action wasn't really effective
       yet, because the IEEE Standards Board still had to confirm that
       action.  Nonetheless, the mover withdrew the motion.  Two other people

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 6 -

       immediately made the same motions in the same order, the motion to
       suspend the rules was approved, and debate ensued on the motion to
       table.

       The above parliamentary foofaraw only took about one minute.  I think
       such amusements are a small price to pay for much less contentious and
       much faster meetings.

       In case you were wondering, eventually the motion to table was voted
       down and the original motion passed.

       5.  PAR Proliferation Prevention

       In the last year, the SEC has approved more than a dozen PARs for new
       committees or new documents.  This sudden (the January 1990 SEC
       meeting approved 11 PARs) doubling of TCOS standards activities has
       led to widespread concern.

       PAR Acceptance Criteria

       In April in Utah, the SEC approved a set of nine criteria for PAR
       acceptance.  These criteria, any of which can be waived by the SEC,
       range from a desire for widespread industry experience and a base
       document to a request for a scope of work that fits within that of
       TCOS-SS.  This was a good first step proliferation prevention, and
       several PARs were either not submitted or were rejected in Snowbird
       because of the existence of the criteria.  This has been reported on
       in previous editorials and snitch reports, and the criteria themselves
       have been posted to comp.std.unix.

       Project Management Committee

       The other half of the battle for committee curtailment was the
       establishment of a standing committee to apply the criteria to PARs
       before they reached the SEC, and to track the progress of committees
       against the milestones in their PARs, so that non-functional
       committees could be recommended for elimination.  A detailed set of
       guidelines (including the PAR acceptance criteria and a model for
       their application) for such a Project Management Committee (PMC) was
       reported out of an ad hoc committee as a motion, which was passed
       unanimously.  The SEC Chair announced the opening of nominations for a
       Chair, Secretary, and Project Editor for the PMC, to be confirmed in
       January.

       Although the movement to curtail proliferation of committees was
       actually started by the Institutional Representatives back in March,
       and though the ad hoc committee that wrote the PMC Guidelines
       originally intended to require a balance of representation in the PMC
       between IRs and other members, no such rule was incorporated in the
       final document.  This was not seen as a problem by the IRs, since the

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 7 -

       PMC cannot make any actual decisions regarding PARs.  The PMC only
       recommends, and cannot even prevent a PAR from coming before the SEC.
       The SEC is the group that must decide on PAR acceptance, and all the
       IRs are members of the SEC.

       We can hope that the existence of the PMC will not only rationalize
       the creation and abolition of standards committees, but will also
       shorten SEC meetings....

       6.  Fees

       The Logistics Subcommittee, chaired by Dave Dodge, returned a report
       advising the raising of fees for meeting attendance.  Traditionally,
       meeting fees helped pay for meeting rooms and related logistics like
       copying machines.  (There is a separate fee schedule for committee
       mailings.) A corporate host was sought for each meeting.  The host
       (e.g., Digital for the Seattle meeting) sponsored lunches four of five
       weekdays and coffee service for breaks.  This wasn't a big deal when
       there were a few committees and maybe a hundred attendees.  But with
       400 attendees these days, hosting a meeting can run up to $55,000, and
       all the host gets is name recognition.  No hosts had been found for
       any meeting after Seattle.  So the logistics committee recommended and
       the SEC approved raising the fees across the board, and giving people
       the option of buying into the lunch plan or not.  This is yet another
       indication of the extent of current standards activities, and of their
       effects on the industry.

       Judy's birthday present

       Various arguments from the logistics committee meeting were reported,
       such as that eliminating coffee might help.  The SEC Chair noted that
       that wouldn't work, since that was how hotels made money, and they
       wouldn't like that.  The USENIX IR remarked that with competent
       management, such as Dave Dodge and meeting organizer Judy Williams,
       there was no need for micromanagement by the SEC at this level.  This
       was apparently the first time anyone had complimented Ms. Williams in
       an SEC meeting.  She organizes the meetings very well, evidently so
       well that most people don't notice.

       Computer room

       One thing the logistics committee could do better would be giving
       direction to sponsors of the computer room (such sponsors are still
       sought, separately from the issue of meeting hosts).  The computer
       room in Seattle had no UUCP or Internet access (although it did have
       half a dozen workstations on a network and a laser printer), and the
       single modem was only 2400bps and not Hayes compatible.  People were
       scrounging mail access from local residents.  Some ideas have been
       floated on how to do this better in New Orleans.

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 8 -

       7.  TIMS gets new PEP from the Spanish Inquisition

       The POSIX Platform Environment Profile (PEP) draft document was the
       base document for a PAR on something that had been submitted at the
       July SEC meeting in Danvers, Mass., as a TIMS (Traditional Interactive
       Multiuser System) PAR.  The PEP PAR was submitted by TCOS-SS Chair Jim
       Isaak, with proposed working group chair Donn Terry.

       Donn Terry is the current chair of IEEE 1003.1, and all the other
       officers of that committee were also proposed to serve for the new
       PAR.  This is a good example of a PAR that doesn't create a new
       committee, rather, it permits an existing committee to produce a new
       document.  (Another good example was the 1003.15 Batch Processing PAR,
       which is being handled by the 1003.10 Supercomputing committee, and
       which was, incidentally, approved in Utah in April after the PAR
       acceptance criteria were approved by the SEC.)

       The PEP PAR says its scope is to ``Establish an [sic] Platform
       Environment Profile based on the ISO 9945 (IEEE 1003 POSIX) work and
       related standards which describes a simple foundation for an
       interactive, multiuser application platform.'' In other words, it's
       YAP (Yet Another Profile).  It fits between more or less between the
       IEEE 1003.0 POSIX Guide, which is a framework or model for writing
       profiles, and the NIST Application Portability Profile (APP), which is
       a list of standards that can be used together.  PEP is intended to
       show how to use standards to specify something that looks like a
       traditional UNIX system.  Unlike 1003.0, it's not closely limited to
       the TCOS standards, and the PAR specifically mentions NIST FIPS,
       X/Open's work, and 9945-1 and 9945-2, as well as alluding to TCOS
       POSIX work like 1003.4.  It even mentions the Houston 30 (an industry
       group of users of standards) as a party that wants this work.  It's
       called a platform profile because it can be used as a base for the
       other profile efforts.

       This was not an especially controversial PAR (except for logistical
       issues such as finding enough people to attend 1003.1 meetings to do
       the work, especially considering that 1003.1 is already mired in LI
       work).  It appeared likely to sail through to approval.  Until someone
       asked to see the answers to the PAR acceptance criteria.  Oops.
       Apparently the proposers had not prepared any, or had only prepared
       them for the previous TIMS PAR, or had not distributed them.  This
       lack almost led to the PEP PAR being tabled.  Instead, the SEC
       convened its version of the Spanish Inquisition: Donn Terry
       volunteered (at the instigation of the USENIX IR) to anwser the PAR
       criteria orally and in real time, and the whole SEC volunteered to
       quiz him on them.  Evidently his answers satisfied enough members,
       since the motion to table was defeated and the PEP PAR was approved
       (despite a complaint from the floor that the SEC's own rules about PAR
       acceptance, as just adopted in the PMC Guidelines, had not been
       followed).

       1 November 1990                                    IEEE/CS TCOS-SS SEC


                                       - 9 -

       The astute reader will have noticed that the Spanish Inquisition was
       held while an undebatable motion to table was on the floor.  How could
       this be?  See above under Robert's Rules....

       8.  USENIX Participation

       At the Tuesday meeting, the USENIX IR asked for Weirdnix submissions
       (for the best legal misinterpretation of 1003.1 or 1003.2) to be sent
       to Jeff Haemer <[e-mail]>.

       The IR then read the main points from the announcement previously
       posted on comp.std.unix about the USENIX Board of Directors decisions
       at their September meeting about standards funding: that the ISO
       Monitor Project was continued (contingent on EUUG support); $15K was
       voted to continue the snitch reports; but no funds were voted for any
       other USENIX standards activities, such as a USENIX Institutional
       Representative (including, among other things, USENIX accreditation to
       the SEC).  The USENIX Board will entertain new proposals at their
       January meeting.  The previous funding expires approximately at the
       end of October 1990.

       At the Thursday SEC meeting, an ad hoc group of SEC members (not
       including the USENIX IR) proposed a resolution to be sent by the SEC
       Chair to the USENIX President and Board of Directors.  The SEC
       approved the resolution without objection, and the Chair thanked them
       for their direction.

       1 November 1990                                    IEEE/CS TCOS-SS SEC


Volume-Number: Volume 22, Number 110

From [e-mail]  Thu Feb  7 12:01:26 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25422; Thu, 7 Feb 91 12:01:26 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Huy Nguyen)
Newsgroups: comp.std.unix
Subject: Where can one find Posix 1003.4a draft 5
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Huy Nguyen)
Organization: Silicon Graphics, Research & Development
X-Submissions: [e-mail]
Date: 7 Feb 91 00:37:49 GMT
To: [e-mail]

Submitted-by: [e-mail] (Huy Nguyen)

Could someone give me a pointer on how to obtain a recent version of the
1003.4a thread proposal(Draft 5)?
Any help would be appreciated.  Thanks.

 [e-mail]

Volume-Number: Volume 22, Number 111

From [e-mail]  Thu Feb  7 12:08:03 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27058; Thu, 7 Feb 91 12:08:03 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Masataka Ohta)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Tokyo Institute of Technology
X-Submissions: [e-mail]
Date: 7 Feb 91 03:32:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Masataka Ohta)

In article <[e-mail]>
    [e-mail] (Peter da Silva) writes:

>Subject: Re: spawn() wars... please... not again...

And you have already lost the war. So, please! not again!

>Leave in the
>fork() call, but allow a more efficient (and, let's face it, easier to
>understand) alternative: spawn().

In the last war, you can't even show a specification of spawn(), because of
its complexity. Every UNIX programmer understand fork() and exec(), but
can't understand spawn() without its specification.

>Leave in the fork() call,

So, you are not trying to eliminate fork().

You should also preserve exec(), because exec() has its own purpose and
several programs are actually using it without fork().

>No. Those are the safe operations between fork() and exec() on UNIX.
>
>POSIX looks like it's going to comprise far more than UNIX.

If fork() and exec() exists in POSIX, many (if POSIX should be useful, all)
operations are safe between fork() and exec().

>Look, I know you don't like spawn(). But in a lot of environments... INCLUDING
>ONES THAT ARE OTHERWISE QUITE CAPABLE OF SUPPORTING A POSIX ABI... it is *not*
>possible to do a safe and efficient implementation of fork().

A lot of? Can you name them?

Anyway, it is the problem of that environment. It should provide safe
and inefficient implementation of fork() and safe and efficient
implementation of system(). If a programmer want to squeeze extra
performance in some case which can not covered by system() (dose such
a case actually exist?), he can do so by not using POSIX there if he
think effeciency is more important than ABI.

>Let's say you define vfork() as "set a flag that all posix calls that deal
>with uid, signals, files, etc... look at, so they just write a "script" of
>actions to take on behalf of the new process".

I can't understand what you are saying. "set a flag"? What?

>> Most (perhaps, more than 90%) of cases where fork/exec is necessary
>> is covered by system(). spawn() is not necessary.
>
>    No, system() and popen() can not, ever, let you pass a set of
>    arguments to a program without diddling by the shell. When you
>    have no way of knowing whether that shell will be sh, csh, ksh,
>    or even rc what can you do to protect yourself?

Read the manual! System() and popen() always use "/bin/sh".

>    Who knows, I can easily imagine DEC setting things up so a user
>    could set his shell to DCL and hose *everything* up.

User's shell has nothing to do with the behaviour of system() nor popen().

>    Using system() in programs like (for example) uucp, mail handlers,
>    and so on is a security hole you can drive a truck through.

Yes, it can be a security hole if used improperly just like many system
calls. I'm sure spawn() can also be a security hole. So what?

                        Masataka Ohta

Volume-Number: Volume 22, Number 112

From [e-mail]  Thu Feb  7 12:18:50 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00605; Thu, 7 Feb 91 12:18:50 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Texas Internet Consulting
X-Submissions: [e-mail]
Date: 7 Feb 91 17:17:56 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

Unfortunately, I'm beginning to hear from readers who are deleting
unread every message in the qfork/spawn discussion.  I have to admit I
tend to agree that there's more heat than light being shown on all
sides of this one.

So, could we please either get back to reasoned technical discussion,
or move on to something else?

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 22, Number 113

From [e-mail]  Thu Feb  7 12:32:21 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04879; Thu, 7 Feb 91 12:32:21 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Michael L. Kornegay)
Newsgroups: comp.std.unix
Subject: Re: Where can one find Posix 1003.4a draft 5
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: oiscola![e-mail] (Michael L. Kornegay)
Organization: NCR/OISD Columbia
X-Submissions: [e-mail]
Date: 6 Feb 91 22:24:43 GMT
To: [e-mail]

Submitted-by: [e-mail] (Michael L. Kornegay)

[ I have linked this message to a previous one on a similar topic.  -mod ]

I am interested in tracking the progress of proposed POSIX threads.

Are they discussed in this newsgroup?  Do mailing lists exists for
its discussion?  Etc.

Currently the proposed POSIX threads I know about are in P1003.4a
draft.  At one time I thought another POSIX group was also working
on threads standardization.

Thanks for your assistance,
--
----------
Michael L. Kornegay,
  [e-mail]
  [e-mail]

Volume-Number: Volume 22, Number 114

From [e-mail]  Thu Feb  7 12:41:31 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07655; Thu, 7 Feb 91 12:41:31 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: OSF Research Institute
X-Submissions: [e-mail]
Date: 7 Feb 91 10:08:32 GMT
To: [e-mail]

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] (Dick Dunn) writes:
> [e-mail] (Simon Patience) writes, among explanations of OSF
> history and status, that:
>
> > OSF/1, simplistically, is the integration of Mach 2.5 microkernel and
> > BSD 4.4...
>
> This is incorrect on two counts.  First, Mach 2.5 is not a "microkernel"
> implementation--it still contains conventional kernel functions.

By this statement I was trying to imply that it was only the microkernel
part of the Mach 2.5 distribution that was used and not the Unix part
(although for the pedants, I'm sure a line or two slipped in). In fact the
Mach 3.0 kernel was based on the 2.5 "microkernel" and only the IPC interfaces
changed significantly (although again I'm sure other changes have been
made, sigh, the things you have to do to protect against flames)

> Second, OSF/1 could not have
> integrated BSD 4.4, because BSD 4.4 is not done yet--at least not accor-
> ding to the folks at Berkeley!  Probably what is meant here is that OSF/1
> has incorporated some of the Berkeley "Reno" code, Reno being the name
> attached to a pre-4.4 release of code intended for developers who want to
> try it out and shake out the bugs.

Well, I did say *simplistically*. In fact OSF and Berkeley worked closely
sharing what was to become 4.3 Reno and will become 4.4. Bugs found and
fixed at OSF will be in 4.4 and vice versa.

If you had wanted a technically precise and accurate description then
you can always attend the OSF/1 internals course.

Simon.

  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                       uunet!gr.osf.org!sp

Volume-Number: Volume 22, Number 115

From [e-mail]  Wed Feb 13 10:01:49 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20835; Wed, 13 Feb 91 10:01:49 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: posix and filesystems
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The Santa Cruz Operation, Inc.
X-Submissions: [e-mail]
Date: 7 Feb 91 17:51:34 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

Given a more-or-less POSIX-compliant system, with multiple filesystem types
(e.g., a "normal" unix filesystem, NFS, and DOS, all mounted at the same
time), does anyone have any ideas what, oh, symlink() should return when
attempted on a filesystem that does not support it?  For various reasons, I
kinda like EINVAL, but I did want to see if anyone else had any ideas, or if
someone could come up with a reference for a "definitive" posix-compliant
answer.

--
-----------------+
Sean Eric Fagan  | "*Never* knock on Death's door:  ring the bell and
[e-mail]      |   run away!  Death hates that!"
uunet!sco!sef    |     -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor")
[phone]   | Any opinions expressed are my own, not my employers'.



Volume-Number: Volume 22, Number 116

From [e-mail]  Wed Feb 13 10:07:32 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22568; Wed, 13 Feb 91 10:07:32 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: IEEE TCOS, New Orleans, January 1991: EurOpen IR's report
Message-Id: <[e-mail]>
Sender: [e-mail]
Subject-References: <[e-mail]>
X-Submissions: [e-mail]
Date: 8 Feb 91 10:37:39 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

Mary Lynne Nielsen, IEEE Project Editor, makes the following
corrections:

> Whenever a possible new POSIX-related
> standards activity is identified, its promoters can draw up
> a Project Authorization Request (PAR), and submit it to the
> Sponsor Executive Committee (SEC) of TCOS.  If approved
> (sponsored in IEEE terminology), and subsequently rubber-
> stamped by the  IEEE Computer Society's Standards Activities
> Board (SAB), a new project is created.
> ...
>    - Balloting groups are drawn from the membership of a
>      balloting pool.  The pool has three types of member:
>      individual members of the IEEE who have specifically
>      applied to join the pool; institutional
>      representatives (IRs) accepted by the IEEE-CS SAB;
>      and national heads of delegation to the ISO
>      POSIX working group.

The CS SAB has no official right to approve PARs, but
approves to send them on to the IEEE Standards Board.  It is
the IEEE Standards Board, which oversees the standards
activities of all 40-odd societies in the IEEE, which grants
actual approval.  Also, the IEEE Standards Board is the
organization that officially approves IR membership status, not
the CS SAB.

--
Dominic Dunlop

Volume-Number: Volume 22, Number 117

From [e-mail]  Wed Feb 13 10:14:11 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24125; Wed, 13 Feb 91 10:14:11 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Eric Gisin)
Newsgroups: comp.std.unix
Subject: ed s/a*/./g description
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
X-Submissions: [e-mail]
Date: 8 Feb 91 20:35:50 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Eric Gisin)

Does anyone have an complete description of how s///g and awk's gsub
handle the special case of an empty pattern match?
The System V documents and POSIX.2 don't cover this.

For example, the command s/[a-z]*/./g does the following on System V ed:
    -bug-    becomes .-.-.
The following algorithm produces an extra dot:
    -bug-    becomes    .-..-.

gsub(pattern, replace, src, dst)
    while (1) {
        find next pattern in src
        copy part before match from src to dst
        copy replace to dst
        advance src to end of match
        if (at end of src)    break;
        /* special case for empty match */
        if (match was empty)
            *dst++ = *src++;
    }


Volume-Number: Volume 22, Number 118

From [e-mail]  Wed Feb 13 10:17:32 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25068; Wed, 13 Feb 91 10:17:32 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: twinsun![e-mail] (Paul Eggert)
Newsgroups: comp.std.unix
Subject: How should one test for seteuid()'s existence?
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Twin Sun, Inc
X-Submissions: [e-mail]
Date: 8 Feb 91 21:43:19 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Paul Eggert)

I've heard that IEEE will publish a separate supplement to IEEE Std 1003.1
(ISO/IEC 9945-1) that covers seteuid(), among other issues.  In the latest
draft of this supplement, how should a program test for the existence of
seteuid()?  Will the following test work?

    #include <unistd.h>

    #if _POSIX_VERSION > 199009L
        ... seteuid() exists ...
    #endif

Volume-Number: Volume 22, Number 119

From [e-mail]  Wed Feb 13 10:22:48 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26834; Wed, 13 Feb 91 10:22:48 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Susanne Smith)
Newsgroups: comp.std.unix
Subject: Re: Where can one find Posix 1003.4a draft 5
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 9 Feb 91 05:26:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Susanne Smith)

Single copies of current drafts of the 1003 documents can be obtained
from the Computer Society with a charge to cover reproduction and mailing.
Their phone number is [phone].

Susanne Smith

Volume-Number: Volume 22, Number 120

From [e-mail]  Wed Feb 13 10:29:20 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29524; Wed, 13 Feb 91 10:29:20 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Ian Vessey)
Newsgroups: comp.std.unix
Subject: IEEE P1003.12 Seeks Input.
Keywords: sockets XTI TLI networking
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 11 Feb 91 20:46:42 GMT
To: [e-mail]

Submitted-by: [e-mail] (Ian Vessey)

The POSIX process-to-process communications working group (P1003.12)
would like to solicit outside comment.

Between November 1990 and January 1991, we asked your opinions as to
whether this working group should

        a)      Develop a 3rd interface akin to sockets and XTI,
        b)      Standardize either Berkeley sockets or XTI,
        c)      Standardize both sockets and XTI.

The results of the poll indicated that

        a)      The working group should not adopt a new third
                interface
        b)      The working group should adopt both sockets and XTI.

These poll results were endorsed by the committee and we are currently
pursuing a plan that provides a single language independent standard
which has two `C' bindings, one for sockets and one for XTI. These
two bindings will constitute our DNI(Detailed Network Interface). We
are also working on an SNI(Simple Network Interface) which views the
network from a far simpler standpoint and operates over the DNI.

The purpose of this mail is to not only feed back the results of the
poll and it's impact on our work, but to ask for further input.
Specifically, we would like comments on perceived problems with either
of the interfaces together with suggestions for additional features
that you believe would be useful to add to one or both of them.

Please keep in mind that backwards compatibility is very important
in any change requests proposed.

As before, please submit your comments to [e-mail].

Volume-Number: Volume 22, Number 121

From [e-mail]  Wed Feb 13 10:38:58 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02495; Wed, 13 Feb 91 10:38:58 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Chuck.Phillips)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
X-Submissions: [e-mail]
Date: 11 Feb 91 11:19:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck.Phillips)

>>>>> On 4 Feb 91 16:32:06 GMT, [e-mail] (Simon Patience) said:

Simon> OSF/1 1.0 was released for general distribution on December 7 1990.

The more important date will be when end users can buy OSF/1 and its
documentation for their machines, IMHO.  The most optimistic rumor I've
heard is third quarter `91 for shipment to end users, and then only for a
few platforms.

Don't get me wrong.  I welcome the competition between USL and OSF.  I'm
confident *both* OSs will benefit as a result.  I wish both camps success.

As a developer of applications that must run on both SVr4 and OSF/1 (when
it ships to end users), I've looked all over for specific information on
the C language interface to OSF/1 in general and system calls in
particular.  The only books I can find on OSF are about Motif, nothing on
the operating system itself.  I'd *like* to take advantage of what OSF/1
offers, but without documentation, this is impossible.  How about sections
1-8 of the man pages for OSF/1?  Where can I buy them?  Telling me it will
be POSIX compliant is only a partial answer.

Disclaimer: Not a spokesman, etc.
--
Chuck Phillips  MS440
NCR Microelectronics             chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO.  80525           ...uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 22, Number 122

From [e-mail]  Wed Feb 13 10:41:40 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03237; Wed, 13 Feb 91 10:41:40 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Chuck.Phillips)
Newsgroups: comp.std.unix
Subject: Re: "#!" magic number  (was: Shell standardization)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
X-Submissions: [e-mail]
Date: 12 Feb 91 15:03:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck.Phillips)

>>>>> On 4 Feb 91 11:50:07 GMT, [e-mail] (Chuck.Phillips) said:
Chuck> Invitation for discussion: If the path after the "#!" doesn't begin
Chuck> with "/", "./" or "../", should PATH be searched for the execuatble?
Chuck> If so, how best could this be implemented?

Based on feedback from Ernest Hua (thanks!), I'd like to ammend this.  SUID
scripts under no circumstances should allow PATH searching for '#!'
arguments -- even if not SUID root.

Continuing the earlier thread, not only are directory structures
non-portable, but some interpreters (e.g. pearl, gawk, bash) have no POSIX
or otherwise defined directory location.  '#!' path searching also allows
vendors to write their own interpreters for scripts without forcing a
particular directory structure on admin.  Further, it allows different
versions of the same interpreter to be used simultaneously based on each
user's path.
--
Chuck Phillips  MS440
NCR Microelectronics             chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO.  80525           ...uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 22, Number 123

From [e-mail]  Thu Feb 14 12:35:33 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17127; Thu, 14 Feb 91 12:35:33 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: OSF Research Institute
X-Submissions: [e-mail]
Date: 13 Feb 91 16:55:39 GMT
To: [e-mail]

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail]
(Chuck.Phillips) writes:
> As a developer of applications that must run on both SVr4 and OSF/1 (when
> it ships to end users), I've looked all over for specific information on
> the C language interface to OSF/1 in general and system calls in
> particular.  The only books I can find on OSF are about Motif, nothing on
> the operating system itself.  I'd *like* to take advantage of what OSF/1
> offers, but without documentation, this is impossible.  How about sections
> 1-8 of the man pages for OSF/1?  Where can I buy them?  Telling me it will
> be POSIX compliant is only a partial answer.

What you want is the Operating System Programming Interfaces Volume of
the AES (Application Environment Specification). This is published by
Prentice Hall ISBN 0-13-043522-8. You should be able to order this from
any reputable bookshop if they don't already have it. It has been available
for some time but I guess it has taken time for the news to leak out.

These are not all the interfaces present in OSF/1 but they are the ones
you should use if you want to write a portable application.

Simon.

  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                       uunet!gr.osf.org!sp

Volume-Number: Volume 22, Number 124

From [e-mail]  Thu Feb 14 14:07:07 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20622; Thu, 14 Feb 91 14:07:07 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Larry Allen)
Newsgroups: comp.std.unix
Subject: Re: recent history of Unix evolution
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Larry Allen)
Organization: Open Software Foundation, Cambridge, Massachusetts
X-Submissions: [e-mail]
Date: 13 Feb 91 19:23:59 GMT
To: [e-mail]

Submitted-by: [e-mail] (Larry Allen)

Speaking not quite authoritatively, but as a member of the
OSF/1 development team:
Most OSF/1 documentation is available without a
source code license.  The "quick-print copies" -
exactly what we shipped on the tape - can
be purchased right now from OSF-Direct.  Call
617-621-7300 and ask to purchase an OSF/1 documentation set.
Prentice Hall versions of several of the manuals will be
available in several months.  I think OSF-Direct
can probably help with information on the printed
books, or talk to your Prentice-Hall salesman...

I should also mention that the OS AES (the Applications
Environment Specification, which is the application
programming interface recommended for use by portable
applications, guaranteed to be preserved across multiple
releases, etc.) is printed by Prentice Hall and is
currently available in better computer bookstores
everywhere :^)  It's called the

Application Environment Specification
Operating System Programming Interfaces Volume

                    -Larry Allen
                     Open Software Foundation

Volume-Number: Volume 22, Number 125

From [e-mail]  Thu Feb 14 14:39:54 1991
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01807; Thu, 14 Feb 91 14:39:54 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: posix and filesystems
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
X-Submissions: [e-mail]
Date: 13 Feb 91 21:55:09 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>Given a more-or-less POSIX-compliant system, with multiple filesystem types
>(e.g., a "normal" unix filesystem, NFS, and DOS, all mounted at the same
>time), does anyone have any ideas what, oh, symlink() should return when
>attempted on a filesystem that does not support it?  For various reasons, I
>kinda like EINVAL, but I did want to see if anyone else had any ideas, or if
>someone could come up with a reference for a "definitive" posix-compliant
>answer.

The definitive answer will appear in the 1003.8 Transparent File Access
standard, when that is completed. (Draft 4 is out for mock ballot and will
be received in the first mailing; mine came today.) Join the ballot group
(opening soon) and have your say.

The specific example of symlink() is not addressed in 1003.8 since symbolic
links do not appear in 1003.1-1990 / IS 9945-1:1990.

The 1003.8 working group has proposed, in draft 4, adding a new error
EOPNOTSUPP which is used to indicate that the action has been requested on a
file accessed over some mechanism which does not support that action.
Overloading EINVAL was investigated and rejected; see the rationale. In some
cases an already-defined error could be unambiguously used; for example,
link() could return EMLINK since the access mechanism may support
LINK_MAX==1 only.

Jason Zions
Chair of, but not speaking on behalf of, P1003.8

Volume-Number: Volume 22, Number 126

From [e-mail]  Mon Feb 18 12:47:29 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA05615; Mon, 18 Feb 91 12:47:29 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (ACMFIU)
Newsgroups: comp.std.unix
Subject: POSIX shell
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Florida International University, Miami
X-Submissions: [e-mail]
Date: 16 Feb 91 04:34:18 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (ACMFIU)

I'm working on a UNIX shell for the Apple IIgs and would like to make it
POSIX conformant, if there is a shell for it. I know nothing about this
standard so if someone can direct me as to where to get a definition of
the shell that POSIX is defining i'd appreciate it.

albert

Volume-Number: Volume 22, Number 127

From [e-mail]  Mon Feb 18 13:26:17 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA14105; Mon, 18 Feb 91 13:26:17 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Ballot groups and mailing lists
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
X-Submissions: [e-mail]
Date: 17 Feb 91 20:26:37 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

I've received several queries in the last few days as to how one might join
a ballot group or get on a mailing list for an IEEE TCOS working group
(POSIX et al). I think it's probably of sufficiently general interest that
posting it to the mailing list as a whole is worthwhile.

To join balloting groups for proposed IEEE TCOS standards (1003.*, 1201.*,
1224.*, 1238.*) you must become a member of the IEEE TCOS Standards
Subcommittee. Joining the TCOS-SS will not itself place you in any ballot
groups, but will cause Invitations to join forming ballot groups to be sent
to you. You cannot join a ballot group which has already "closed". Ballot
groups are generally "open" between 3 and 6 months. When writing, you should
probably inquire as to which ballot groups are still forming (i.e. open).

The sole prerequisite for membership is membership in either the IEEE itself
or the IEEE Computer Society. To join TCOS-SS, please write to:

Computer Society Secretariat
IEEE Standards Office
445 Hoes Lane
Piscataway, NJ  08855

Give your name/address/phone&fax/e-mail addr and IEEE or IEEE-CS membership
number. Also, retain a copy of your application for your own records. You
should receive confirmation from the IEEE within 2-3 weeks; if you do not,
start looking into it.

 - - -

Belonging to the ballot group will only cause you to receive formally-
balloted drafts. To obtain information on joining working group mailing
lists, which contain interim drafts and other working documents, please
direct your inquiry to:

[[ Editor - please check the following address. I think Lisa's office is the
correct one; if so, the address is correct. I know writing to NAPS directly
is not the approved way of doing this. Help! ]]

Lisa Granoien
IEEE Computer Society
1730 Massachusettes Avenue NW
Washington DC  20036
Fax: [phone]

Be aware that mailing list membership entails a charge based on the cost of
reproduction and distribution of the materials subscribed to; monies are
required up-front and costs are dedcuted from your balance as time goes on.
Additional details are included in the mailing list application form.

 - - -
Regards,

Jason Zions
Chair, IEEE P1003.8 POSIX Transparent File Access


Volume-Number: Volume 22, Number 128

From [e-mail]  Mon Feb 18 13:31:41 1991
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA15704; Mon, 18 Feb 91 13:31:41 -0500
Received: by cs.utexas.edu (5.64/1.94)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Ballot groups and mailing lists
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 18 Feb 91 18:30:53 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

Moderator!:

>[[ Editor - please check the following address. I think Lisa's office is the
>correct one; if so, the address is correct. I know writing to NAPS directly
>is not the approved way of doing this. Help! ]]

I don't know what editor you're referring to.

The address you give resembles the one recommended at the end of the
Introduction to IEEE Std 1003.1-1990 for the IEEE/CS Standards Status Report,
which lists all current IEEE/CS standards projects:

    IEEE Computer Society
    1730 Massachusetts Avenue NW
    Washington DC  20036-1903
    Fax: [phone]

That Introduction indicates that those interested in participating in TCOS
working groups should send their name, address, and telephone number to

    Secretary
    IEEE Standards Board
    Institute of Electrical and Electronics Engineers, Inc.
    P.O. Box 1331
    445 Hoes Lane
    Piscataway, NJ  08855-1331

and should ask that their message be forwarded to the chair of the
specific group they're interested in.

You don't have to join a balloting group to get mailings, nor to
attend Working Group meetings.

Descriptions of every TCOS group, with chairs, may be found in:

    Smith, Susanne W., and Quarterman, John S.,
    ``Open Systems Standards Resource Guide,''
    UNIX Technology Advisor, vol. 2, no. 8,
    pp. 12-15, MYOB, Hollis, NH, August 1990.

Similar information appears in the postings that the same two authors
sometimes make to USENET, and in a printed calendar.  Those postings
will probably reappear when we get sufficient time from working on
other (paying) projects.

The simple answer that I usually give is to contact the TCOS-SS chair,
Jim Isaak <[e-mail]>, and let him distribute to the appropriate
committee chair.  He hasn't complained yet.  :-)

--
John S. Quarterman
Texas Internet Consulting    [e-mail]    tel: [phone]
701 Brazos, Suite 500      uunet!longway!jsq    fax: [phone]
Austin, TX 78701

Volume-Number: Volume 22, Number 129

From [e-mail]  Sat Feb 23 15:36:00 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA29073; Sat, 23 Feb 91 15:36:00 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Dan Oldman)
Newsgroups: comp.compilers,comp.lang.c++,comp.lang.c,comp.lang.fortran,comp.std.unix,comp.unix.wizards
Subject: UI Programming Languages SIG
Keywords: debug, linker, design
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Dan Oldman <[e-mail]>
Followup-To: comp.compilers
Organization: Data General Corporation, Research Triangle Park, NC
X-Submissions: [e-mail]
Date: 19 Feb 91 17:46:37 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dan Oldman)

The UNIX International Programming Languages Special Interest Group (UI
PLSIG) is an organization of people interested in improving programming
language tools on UNIX System V release 4 and beyond.

Our current focus is on expanding and refining the specification of the
debugger information format which is used by the portable tool set
(e.g. C compiler, symbolic debugger) in AT&T's System V Release 4 and
by some other third party software development tools.  This new
information format is called DWARF.

In the future we intend to enhance and/or develop specifications for
DWARF "bindings" for FORTRAN, C++, Modula, and other interesting
languages, as well as specifications for the kernel and shared library
manager (RTLD) interface for debugging and core files.  After debugging
support has advanced to a "maintenance activity" for us, we are
interested in other areas but have no specific plans.

The plsig operates via email and about 5-6 meetings per year held at
facilities provided by volunteer members.  Our next meeting is planned
for late April at Motorola in Austin, Texas.  People who can't
physically attend are encouraged to participate via email.  The mailing
list is quite active and is the vehicle for distributing minutes from
our meetings and proposed drafts of documents.

To get on the mailing list, send your name, surface mail address, phone
number, email address, and fax number if you have one to
[e-mail].  Specific questions can also be addressed to the
chairman (Dan Oldman) at "[e-mail]".

Volume-Number: Volume 22, Number 130

From [e-mail]  Sat Feb 23 15:58:10 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA01516; Sat, 23 Feb 91 15:58:10 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Status of call for new moderator?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 21 Feb 91 08:28:58 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

Could we please have a brief update on the status of the search for a
new moderator for this newsgroup?  Thank you.
--
Dominic Dunlop

Volume-Number: Volume 22, Number 131

From [e-mail]  Thu Feb 28 09:52:19 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA01461; Thu, 28 Feb 91 09:52:19 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: New moderator: speak now...
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Mindcraft, Inc.
X-Submissions: [e-mail]
Date: 26 Feb 91 20:23:20 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

After withdrawals from candidacy by all the other volunteers,
Sean Eric Fagan ([e-mail]) is the provisional replacement
moderator for com.std.unix.

If there's any objection to simply accepting him as the new moderator
by acclamation, please speak up now, either by posting or by E-mail to
me ([e-mail]).  If I don't hear anything within a week of
the time I see this posting come back from John, I'll send an
announcement to news.announce.newgroups that the reins have been
shifted.

One of the other volunteers has expressed concern about perceptions of
possible conflict of interest, in that Sean is an employee of a major
UNIX vendor.

I have several answers to this concern.

First, the idea that anyone can be truly objective about anything is a
polite fiction at best.  We all try to be fair, and a good-faith effort
in this direction is all we can hope for.  If anyone thinks the
moderator is showing bias, USENET offers plenty of channels to express
dissatisfaction, both public and private.

Second, all of us have our own axes to grind, as users, as vendors, or
as service providers.  The fact that a particular axe may be sharpened
by the thought of commercial advantage doesn't make it any more or less
legitimate than one that comes from a different set of preferences.  I
suggest that we use the approach that the POSIX committees use:  Every
participant is assumed to speak for her/himself.  It's assumed that ALL
participants have something at stake, or they wouldn't bother to do all
that work.

Third, Sean has agreed to post some sort of disclaimer cooked up with
the help of his employer's legal staff.  I hope I don't have to page
past it too many times; I don't really think it's necessary.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

Volume-Number: Volume 22, Number 132

From [e-mail]  Fri Mar  1 16:43:46 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA16952; Fri, 1 Mar 91 16:43:46 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Peter Salus)
Newsgroups: comp.std.unix
Subject: Re: New moderator: speak now...
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: The World @ Software Tool & Die
X-Submissions: [e-mail]
Date: 1 Mar 91 14:37:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Salus)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>Submitted-by: [e-mail] (Chuck Karish)
>
>After withdrawals from candidacy by all the other volunteers,
>Sean Eric Fagan ([e-mail]) is the provisional replacement
>moderator for com.std.unix.
>
>If there's any objection to simply accepting him as the new moderator
>by acclamation, please speak up now, either by posting or by E-mail to
>me ([e-mail]).

I don't object to Sean, I just want to know why.  I earlier posted
a request as to the reasoning behind having a moderator at all.
I received a response citing .wizards as an instance of a group
that went out of control.  But I note that the other std groups
aren't moderated (e.g. international, c, mumps) and that they have
not gone berzerk.

Peter

------------------------------------------------------
Note:  The Sun User Group's address is now
    Suite 315
    1330 Beacon St.
    Brookline, MA 02146
--
The difference between practice and theory in practice is always
greater than the difference between practice and theory in theory.

Volume-Number: Volume 22, Number 133

From [e-mail]  Sat Mar  2 17:12:57 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA01909; Sat, 2 Mar 91 17:12:57 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Vijay (Ender))
Newsgroups: comp.std.unix
Subject: What are Unix V9 et al. ?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Vijay (Ender)
Organization: Marquette University - Department MSCS
X-Submissions: [e-mail]
Date: 2 Mar 91 15:53:44 GMT
To: [e-mail]

Submitted-by: [e-mail] (Vijay (Ender)

I have seen several references to Unix V{8,9,10} and my interest
was piqued.  I have the following questions about them.

1.    What are they.  Are they the next logical step up from V7?

2.    Are they any good?

3.    Are they only for research in Universities or are they available
        commercially?

4.    What, if any, use are they?

Please e-mail and I will summarize.

cheers
-dicky gill (Violator)
[e-mail]

Volume-Number: Volume 22, Number 134

From [e-mail]  Sun Mar  3 10:25:18 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA21802; Sun, 3 Mar 91 10:25:18 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: What are Unix V9 et al. ?
Summary: a brief note on research unix
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
X-Submissions: [e-mail]
Date: 3 Mar 91 13:28:50 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

    there have been several snippets on research unix over the last year
or so but a quick summary would not be amiss. Unix V* refers strictly to
editions of the manual; of course, there are corresponding versions of the
system but rarely did anyone go to the trouble of making a distribution
tape (one was done for V8). The versions (and highlights) are
    8th Edition (Feb, 85): streams, much networking (mostly datakit),
remote filesystem (wienberger's), Blit software and support.
    9th Edition (Sep 86): cleanup of 8th Edition, manual MUCH improved,
libraries and source cleaned and trimmed. Much improved networking, including
IP and better text processing (monk, prefer, vtbl).
    10th Edition (Oct 89): 20th anniversary edition! This edition included
both volumes; the 2nd volume (supporting documents) was heavily revised
and enlarged. Both volumes are available as a set from Saunders for $45 in the US
(i am working with Saunders in Canada on the price there). Code highlights
include a sensible mailer scheme (upas), simplified networking, more
specialised programs such os OCR readers, protocol verification tools,
better windowing software (including the editor sam) and a host of
gradual improvements to older programs.

    Any enquiries about Research Unix can be sent to me
([e-mail]) or my department head, Dennis Ritchie
([e-mail]). It may be possible for educational places
to get a 10th edition tape; if you are interested, contact dennis.
Also note that educational people interested in using Plan 9,
an alternative newer distributed operating system developed in
our Center by Pike, Presotto, Thompson, Trickey and others,
should contact Rob Pike ([e-mail]) for details.

Volume-Number: Volume 22, Number 135

From [e-mail]  Mon Mar  4 15:26:18 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA20237; Mon, 4 Mar 91 15:26:18 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: New moderator: speak now...
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Texas Internet Consulting, Austin, Texas 78701
X-Submissions: [e-mail]
Date: 4 Mar 91 20:22:16 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

The first article in the newsgroup comp.std.unix (then known as mod.std.unix)
was posted 25 June 1985.  Members of the IEEE P1003 standards committee
(there was only one such committee back then) had requested that the new
newsgroup be moderated to avoid the noise level seen on other newsgroups.
To date there has been only one moderator, me.  However, I would like to
thank all those who have served from time to time as guest moderators,
particularly John B. Chambers and Fletcher Mattox.

As noted in previous postings, I have decided to retire as moderator.
Subsequent to my posting of 31 January 1991 calling for volunteers to
be moderator, six people came forward by the deadline of 15 February
(and a couple of others said they would volunteer if nobody else
did).  The last to definitely volunteer by the deadline was Chuck
Karish, who, by the rules I had stated, then proceeded to determine
which of the volunteers was to become moderator.  He chose to do this
by discussions among the volunteers for the position.

I have been informed by both Chuck and by Sean Eric Fagan that Sean was
chosen by the withdrawals from candidacy of all the other volunteers.
Chuck announced this result in his posting to the newsgroup of 26 February.
He also announced

    If I don't hear anything within a week of the time I see this
    posting come back from John, I'll send an announcement to
    news.announce.newgroups that the reins have been shifted.

While I have deliberately given no advice as to who should be moderator
or how the new moderator should run the newsgroup, and I deliberately
did not participate in the decision process by which Sean was chosen
from among the six candidates, I would nonetheless like to assert that
the procedure outlined above was as I had requested.

I have seen no objections to Sean Eric Fagan being the new moderator of
comp.std.unix.  Unless I see some or Chuck Karish <[e-mail]>
informs me that he has seen some, I will post the final article in
comp.std.unix Volume 22 before midnight CST Wednesday 6 March 1991.
Sean Eric Fagan will take over Thursday as moderator of comp.std.unix.
He is already in the aliases [e-mail] (postings) and
[e-mail] (comments), and has apparently decided to
keep those aliases, so there should be no lost submissions.

The outgoing moderator hopes the new moderator has a successful newsgroup.

John S. Quarterman
[e-mail]
[phone]
fax: [phone]
Texas Internet Consulting
701 Brazos Suite 500
Austin, Texas  78701

Volume-Number: Volume 22, Number 136

From [e-mail]  Mon Mar  4 19:12:15 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA19215; Mon, 4 Mar 91 19:12:15 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Alex Martelli)
Newsgroups: comp.unix.shell,comp.std.unix
Subject: Re: Retaining file permissions
Keywords: chmod, sed, awk... and good old *cat*!
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Followup-To: comp.std.unix
Organization: Premiata Famiglia Martelli & Figli
X-Submissions: [e-mail]
Date: 2 Mar 91 15:48:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Alex Martelli)

[e-mail] (Jonathan I. Kamens) writes:
    ...
    (I assert that cat one>two keeps all permission bits on two)
:You must have a pretty strange version of cat on your system, or a
:brain-damaged kernel that does not clear the setuid bit when a file
:is written to.

It's not the cat-s (I've tried both /bin/cat and /usr/local/gnubin/cat
and I have the source to the latter so I can check), so it must be
what you describe as "brain-damage" in the kernel.  Personally, I
don't see why open() or write() should ever change the file's permission
bits; sure it allows you to do silly things, but then if you care
about security you won't keep files that are executable, and world
writable, at the same time, will you?
Anyway the allegedly-broken kernel is Interactive 2.2, but I believe
others will behave similarly; I'll check at work.

:|> What behavior will Posix.2 mandate?
:
:  I believe POSIX mandates that, for security reasons, the setuid and setgid
:bits on a file should be cleared whenever the file is written to.  If that
:isn't in the standard, then the standard is broken; then again, we already
:knew that, so it isn't a surprise.  Further, I would find it very hard to
:believe that POSIX says that cat is supposed to notice if stdout is a file and
:do an fstat on it before it writes to it to get the permission bits, and then
:do an fchmod afterwards to restore them to their initial conditions.

It would definitely make sense that cat a>b "do the natural thing" - IF
the kernel must muck with permission bit on write()s to b, then it
would hardly make sense for cat to have to undo it, and viceversa, if
the kernel leaves b's permission bits alone, then so should cat
(should the SHELL try to change permission bits in the redirected-to
file before exec'ing cat??? I would DEFINITELY hope not!).  I have
redirected followups to comp.std.unix since it seems more of a standard
related question.  So, what DOES Posix say about this (open(), write(),
cat, shell redirection, and permission bits), and what SHOULD it say?
--
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) [e-mail], (home:) [e-mail]
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

Volume-Number: Volume 22, Number 137

From [e-mail]  Tue Mar  5 03:26:39 1991
Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway)
    id AA12292; Tue, 5 Mar 91 03:26:39 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Vincent B. Wayland)
Newsgroups: comp.std.unix
Subject: Where / How to get Posix Documents?
Keywords: Posix,documents,standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: isis![e-mail] (Vincent B. Wayland)
Organization: Math/CS, University of Denver
X-Submissions: [e-mail]
Date: 5 Mar 91 05:45:07 GMT
To: [e-mail]

Submitted-by: [e-mail] (Vincent B. Wayland)

Where and how does one go about getting copies of the various Posix documents?
Are they available via email or FTPing?  3 1/2" diskette?  I also mean the
various draft standards-to-be, too.

Thanks,
Vince Wayland
215 Cimmaron Way
Boulder, CO  80303

[phone]

Volume-Number: Volume 22, Number 138

From [e-mail]  Wed Mar  6 18:08:45 1991
Received: by uunet.uu.net with UUCP (5.61/UUNET-primary-gateway)
    id AA27041; Wed, 6 Mar 91 18:08:45 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Peter Barnes)
Newsgroups: comp.std.unix
Subject: Thank you, John!
Summary: Vale!
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 5 Mar 91 20:11:16 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter Barnes)

John S. Quarterman writes:
> The first article in the newsgroup comp.std.unix (then known as mod.std.unix)
> was posted 25 June 1985. [...]
> To date there has been only one moderator, me.  However, I would like to
> thank all those who have served from time to time as guest moderators,
> particularly John B. Chambers and Fletcher Mattox.
> As noted in previous postings, I have decided to retire as moderator.

I, and I expect many others on the net, would like to express my thanks to
John for the work he has done over nearly six years in this newsgroup.

In that time the group has been valuable in raising public awareness in the
standards process, providing wide, easy and rapid access to pertinent
information, and providing a forum for much valuable discussion of standards
issues.

Many people have made contributions to the group, but John has held it
together.

Thank you!

Peter
-------------------------------------------------------------------------------
Peter Barnes  [e-mail]
Secretary, AUUG Inc.

Volume-Number: Volume 22, Number 139

From [e-mail]  Wed Mar  6 18:36:16 1991
Received: by uunet.uu.net with UUCP (5.61/UUNET-primary-gateway)
    id AA03604; Wed, 6 Mar 91 18:36:16 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Retaining file permissions
Summary: Changing set-user-id bit on write
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Mindcraft, Inc.
X-Submissions: [e-mail]
Date: 5 Mar 91 23:46:58 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail] (Alex Martelli) writes:
>So, what DOES Posix say about this (open(), write(),
>cat, shell redirection, and permission bits), and what SHOULD it say?

POSIX.1 clause 5.6.1.2, descriptions of S_ISUID and S_ISGID bits:  "On
a regular file, this bit should be cleared on any write."

Note the word "should".  This is a recommendation to implementors, not
a requirement.

BSD 4.3 write(2) man page: "If the real user is not the super-user,
then write() clears the set-user-id bit on a file."

Interactive man pages for stat(2), write(2), and chmod(2) are silent on
this issue.

POSIX.2 is pretty much constrained to accept as valid behavior that's
allowed/suggested by POSIX.1.  I don't think there are any requirements
that the utilities second-guess and defeat the file access policies
that could legitimately be imposed by an underlying POSIX.1 operating
system.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

Volume-Number: Volume 22, Number 140

From [e-mail]  Wed Mar  6 18:37:17 1991
Received: by uunet.uu.net with UUCP (5.61/UUNET-primary-gateway)
    id AA03922; Wed, 6 Mar 91 18:37:17 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Retaining file permissions
Keywords: chmod, sed, awk... and good old *cat*!
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 6 Mar 91 18:21:22 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donn Terry)

In article <[e-mail]> [e-mail] (Alex Martelli) writes:

>It would definitely make sense that cat a>b "do the natural thing" - IF
>the kernel must muck with permission bit on write()s to b, then it
>would hardly make sense for cat to have to undo it, and viceversa, if
>the kernel leaves b's permission bits alone, then so should cat
>(should the SHELL try to change permission bits in the redirected-to
>file before exec'ing cat??? I would DEFINITELY hope not!).  I have
>redirected followups to comp.std.unix since it seems more of a standard
>related question.  So, what DOES Posix say about this (open(), write(),
>cat, shell redirection, and permission bits), and what SHOULD it say?

POSIX.2 (where cat is discussed) is silent on the subject, because it
relies on the underlying system behavior, which doesn't have to be
POSIX.1.  (It could be <your favorite absurd OS name here> as long
as some specific requirements for minimal similarity to POSIX.1 are met.)

POSIX.1 says "On a regular file, [the S_ISUID] bit should be cleared
on any write."  (P102, L684 and 688).

Two key things here:  "should" (not "shall") and "write" (not write() in
italics).

"Should" is a recommendation, not a requirement.  Thus, a conforming
system doesn't have to do it.  This is compromise wording, as some
existing implementations would not conform if that was a requirement.
(This is a consequence of the definition of "should".)

"Write" means any write operation, not specifically the write() system
call.  (This is a judgement call on my part, and should not be taken
as in any way official.)

There are those who would (and did) argue that it's "brain-damaged" to
clear the bit, and those who would (and did) argue the other way.

A relevant digression into the use of a standard as a tool for
purchasing, and how it fits into this kind of problem.

If you care, it's perfectly reasonable in a RFP (or any other purchase)
to specify any "should" as a "shall" (or "shall not").  NIST did that in
one place in FIPS 151-1.  X/Open has done it in several places.  In the
long run, if a clear consensus develops that some "should" is always or
never required, the standard can change to make it a "shall" or "shall
not".  (Someone has to care enough to make that happen during the
next revision, but if the consensus is there, it's not hard.)

When you specify a bunch of options, it can be called a "profile".
There is work on both de-facto standard profiles (X/Open and NIST
qualify here) and on formal ones (IEEE 1003.<several>).  Since profiles
can often be "lighter weight" documents than a typical POSIX standard,
some of the should/shall issues can be addressed in them more rapidly
than in the base standards.  (This might be either because the
marketplace consensus has formed, or that for the narrower market niche
that the profile addresses, there already is a consensus.)

In this specific case, the profile for the folks who think not clearing
the set user ID bit is brain-dead would require a shall; for others
they could leave it alone, or maybe even require "shall not".

Sidelight:  Because I work for a vendor, I shudder to think that "shall
not" would ever actually be required for this case; this makes a problem
for vendors in that now we have to have another implementation option (or two
different implementations!).  It also makes problems for users because
it will cost more to implement the option (OK, not much, but they add
up) which will be passed on to the user, and the costs of administering
go up (again, they add up in complexity, probably geometrically).
Formal profiles (again, such as X/Open or NIST or IEEE) help assure
consistency in the choice of options, making it easier to lower the cost
of implementation, which translates into lower costs for the customer.

Donn Terry
Chair, IEEE 1003.1

Speaking only for myself; no part of this should be construed as anything
but my opinion, and specifically not as the opinion of either IEEE or
my employer.  (I have to say this to keep IEEE happy; I don't blame
them for requiring it, given the consequences.)

Volume-Number: Volume 22, Number 141

From [e-mail]  Wed Mar  6 18:37:35 1991
Received: by uunet.uu.net with UUCP (5.61/UUNET-primary-gateway)
    id AA03972; Wed, 6 Mar 91 18:37:35 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (Peter Salus)
Newsgroups: comp.std.unix
Subject: Re: New moderator: speak now...
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: The World @ Software Tool & Die
X-Submissions: [e-mail]
Date: 6 Mar 91 14:58:15 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Salus)

In article <[e-mail]> [e-mail] (John S. Quarterman) writes:
>Submitted-by: [e-mail] (John S. Quarterman)
>
>The first article in the newsgroup comp.std.unix (then known as mod.std.unix)
>was posted 25 June 1985.  Members of the IEEE P1003 standards committee
>(there was only one such committee back then) had requested that the new
>newsgroup be moderated to avoid the noise level seen on other newsgroups.
>To date there has been only one moderator, me.  However, I would like to
>thank all those who have served from time to time as guest moderators,
>particularly John B. Chambers and Fletcher Mattox.
>
>As noted in previous postings, I have decided to retire as moderator.

As someone who has read nearly every posting in this group since
early in 1986, I would like to publically and formally express
my gratitude and appreciation for all John has done, for the
standards and the UNIX communities.

John, we will miss you.

Peter
--
The difference between practice and theory in practice is always
greater than the difference between practice and theory in theory.

Volume-Number: Volume 22, Number 142

From [e-mail]  Wed Mar  6 21:40:33 1991
Received: by uunet.uu.net with UUCP (5.61/UUNET-primary-gateway)
    id AA25755; Wed, 6 Mar 91 21:40:33 -0500
Received: by cs.utexas.edu (5.64/1.95)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End of comp.std.unix Volume 22.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Texas Internet Consulting
X-Submissions: [e-mail]
Date: 7 Mar 91 02:28:49 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

This is the end of comp.std.unix Volume 22.

It is also the last article posted by the old moderator.
However, despite what a recent posting might lead you to believe,
I am retiring only from moderating the newsgroup, and not from
the UNIX, standards, or networking communities.  Nonetheless,
thanks to those who have sent complimentary messages.

I checked with Chuck Karish today, and neither he nor I have
received any objections, so Sean Eric Fagan now becomes the
moderator of the newsgroup.

John S. Quarterman
[e-mail]
[phone]
fax: [phone]
Texas Internet Consulting
701 Brazos Suite 500
Austin, Texas 78701
U.S.A.

Volume-Number: Volume 22, Number 143