Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26

Internet Message Format | 1992-02-21 | 319KB

From [e-mail]  Mon Nov 18 16:00:35 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02081; Mon, 18 Nov 91 16:00:35 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13967; Mon, 18 Nov 91 15:59:07 -0500
Newsgroups: comp.std.unix
From: Sean Eric Fagan <[e-mail]>
Subject: Policy and Guidelines for comp.std.unix
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 18 Nov 1991 20:46:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

This is a policy statement for comp.std.unix.

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

Subject: 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, GNU,
    and the USENIX Standards Watchdog Committee.

Subject: Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is Sean Eric Fagan.

Subject: Disclaimer.

Postings by any committee member 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.  Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.

* 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.


Subject: 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

In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or cygnus.com (e.g., [e-mail]).  If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.
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, kithrup.com, or cygnus.com.
There are also occasional guest moderators, who may post from still other
machines.  Guest moderators are announced in advance by the regular moderator.

Subject: 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/usenet/comp.std.unix/archive
or
        ~ftp/usenet/comp.std.unix/volume.25
The previous volume may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.24.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/usenet/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/usenet/comp.std.unix; ls -l" is in
        ~ftp/usenet/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


Subject: 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.

The previous moderator claimed a 90% acceptance rate; 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.  If a message
appears to be directed towards me, I will reply; if I am unsure, I wil ask
the sender if posting is really necessary or desired.

Very occasionally I may reject an article outright:  this will most likely
be 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.



Subject: 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.
    Very occasionally, this might cause an improper address
    to be generated.  If this occurrs, and you think you may
    submit an article again, send me a note, and I will attempt
    to use an address you suggest next time.
+ 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.  Due to the way news is transmitted,
articles may appear out of order at some sites if I send out several
at once.

Also, signatures that are excessively long may be truncated.



Subject: 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.

Subject: 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.  (This includes multiple blank lines at times.)

Lines longer than 80 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



Subject: 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 Stephen
E. Walli <[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.

Sean Eric Fagan, moderator, comp.std.unix and [e-mail].

Volume-Number: Volume 26, Number 1

From [e-mail]  Mon Nov 18 21:06:06 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21245; Mon, 18 Nov 91 21:06:06 -0500
Received: from kithrup.com (via [140.174.1.40]) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23989; Mon, 18 Nov 91 16:40:54 -0500
Newsgroups: comp.std.unix
From: Randall Howard <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 18 Nov 1991 16:30:19 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Randall Howard)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>Submitted-by: [e-mail] (Dan Bernstein)
[Some lines deleted... -- poster ]
>If that's the state of standardization of the current market, then yes.
>Letting POSIX control UNIX is like turning the United States President
>into a dictator with absolute power to make the law.
>
>What makes standard-writing so attractive is that it strokes your ego.
[ more lines deleted -- mod ]
>I wish POSIX would stop shooting off into the cosmos, come back to
>earth, and spend some time documenting what UNIX systems actually *do*.
>

Dan, you've missed the most important thing that differentiates a
consensus based standards process like the IEEE, ANSI, and ISO (i.e.
POSIX) from vendor or consortia-based standards like SVID or SVR4.
That point is that you, and everyone else, are allowed to both
participate in the working group that created the standard and to
ballot on the result produced by that working group.  You participate
in the IEEE as an individual, coming to the table with an informed
opinion on what the standard should look like.  You seem to imply that
the standard is autocratically created by a powerful clique of one or
more people who act (collectively) like a dictator.  If you are that
interested and concerned about these issues, put your money where your
mouth is and participate in this balloting process.

I say these things as a member of both balloting and working groups
that created both POSIX.1 and POSIX.2 standards.  Yes, it was a
frustrating process, particularly for a technical person used to seeing
quick results.  However, the most annoying thing is these gratuitous
comments made by people who have not taken the time to participate in
the process themselves.  I feel that this is important, because if you
participated you would know that the process does not work in the
simplistic (or indeed sinister) way you suggest.



Volume-Number: Volume 26, Number 2

From [e-mail]  Tue Nov 19 20:44:38 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19640; Tue, 19 Nov 91 20:44:38 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25314; Tue, 19 Nov 91 20:44:36 -0500
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 18 Nov 1991 19:08:50 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] writes:
> Typical example: the /etc/rc and /etc/rc.local script to fire up
> multi-user mode.

> seems SVRx has buried this once simple and easy-to-manage concept
> into directories like /etc/rcN.d.

As someone who administers a wide variety of Xenix, System V, and BSD UNIX
boxes, I'd like to say that the /etc/rcN.d scheme is *FAR* superior to the
old /etc/rc.local setup. You want to do something at startup? Just move a
file into a directory. You want to remove a software package? Just remove
this file... of course Sun doesn't *have* a concept of a "software package".

The additional features of SunOS over V.3.2 are really nice, but the basic
system integration in V.3.2 is way better, and if you have more than one or
two systems to administer it more than makes up for the shorter feature list.

> 184 lines is something i would suppose that even a very dumb
> sysadmin could cope with.

Multiply that by a few dozen systems, each with their own hardware setup?

We added an /etc/rc.d to our Xenix boxes as soon as we saw the System V
scheme. When they quit reinstalling the Suns every other day we'll do
something similar there.

I don't know what POSIX is specifying here, but I hope it's something more
similar to System V than BSD. Though with my luck they'll use ASN.1 for
everything. :->
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"

Volume-Number: Volume 26, Number 3

From [e-mail]  Tue Nov 19 21:34:37 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22391; Tue, 19 Nov 91 21:34:37 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07465; Tue, 19 Nov 91 21:34:31 -0500
Newsgroups: comp.std.unix
From: Jason Zions <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard,     Information Networks Group
Date: Wed, 20 Nov 1991 00:59:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Doug Gwyn said:

>No, what I was really
>complaining about is the large amount of committee invention in 1003.2,
>especially such atrocities as "c89", the regular expression mess, and a
>rash of commands and options not previously implemented in ANY version of
>UNIX.

In another message, someone else had pleaded that POSIX standardizers get
their head out of the clouds and actually standardize what had already been
implemented. (I'll ignore the implied insult that most POSIX writers are not
in fact implementors; direct contradiction with reality.)

The "c89 atrocity" to which Doug refers is a perfect example of the kind of
invention made *necessary* by *existing implementations*.

The typical C compiler has between 30 and 60 options, using most of the
lower- and upper-case letters. If one were to take the union of all features
provided by the top 5 non-commonly-derived implementations, one might find
around 60 unique options implemented by two or more of those five; if one
were to be selective and try to identify the options which represent the
concensus of implementations, one might find, oh, 40 or so.

Now, suppose vendor A has implemented one of those options, and it is
invoked by using the -P option. Similarly, vendor B's compiler implements
the same option, but used -S for it, and put another of the 40-odd concensus
options on -P. Tell me, which option should the standard "cc" turn on when
the -P option is used? The one vendor A put there, or the one vendor B put
there? Either way, shell scripts already existing on machines built by A or
B will suddenly, and silently, stop working correctly. There's no way for a
vendor to offer a graceful cut-over period; when a user rolls to the
1003.2-conforming release, all those makefiles and shell scripts which
invoke cc with the changed options will break.

The "c89" solution, ugly as it may be, offers vendors, and users, an
opportunity to gracefully shift over to the new, standard, option set. A
vendor will continue to provide the same "cc" driver they provide today,
with the same non-standardized set of options. At the same time, the vendor
would also provide a "c89" driver which understood the new, standard, option
set. Makefiles and shell scripts could be converted at leisure, and
converted and unconverted scripts could coexist on the same system. Two or
three releases into the future, a vendor could obsolete the old option set
for "cc" and make that command a synonym for c89, if they so chose.

At the same time, the c89 option space is cleaned up and more rigorously
controlled; this means that new standard options can be added in the future
without needing to go through this mess again.

The only thing which is perhaps atrocious about "c89" is the name itself. It
had to be different from "cc"; what would you have chosen?

As regards the "commands and options not previously implemented", many of
them are directly implied by the stuff in 1003.1 (the pathconf-related shell
commands come to mind). If those kinds of changes were important enough to
application portability to be put in 1003.1, why would similar changes not
be needed to help ensure script portability?

The "regular expression mess" was similar to the c89 problem, but worse;
they couldn't change the command names to separate the regexp letter names.
More than that, regexp's as usually implemented were hopelessly
ethnocentric; changing languages was impossible. All POSIX standards have an
*explicit* goal of being International (ISO) standards; non-English support
is *required* to meet that goal, as ISO JTC1/SC22/WG15 has made abundantly
clear. Given the fact that the union of common implementations resulted in
most of the useable characters being given conflicting meanings, and that a
"good" standard causes equal pain for everyone instead of favoring one of
the implementations over others, how would *you* have resolved it?

Doug, you mentioned your original proposal to 1003.2 all those years ago.
How did that proposal address overlap of options in the most common
implementations, hopeless English-centrism, and the like?

Jason Zions

Volume-Number: Volume 26, Number 4

From [e-mail]  Thu Nov 21 17:45:41 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07462; Thu, 21 Nov 91 17:45:41 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05479; Thu, 21 Nov 91 17:45:28 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Nov 1991 01:07:51 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Randall Howard writes:
> Dan, you've missed the most important thing that differentiates a
> consensus based standards process like the IEEE, ANSI, and ISO (i.e.
> POSIX) from vendor or consortia-based standards like SVID or SVR4.
> That point is that you, and everyone else, are allowed to both
> participate in the working group that created the standard and to
> ballot on the result produced by that working group.

So what?

Are you saying that it's okay to ``standardize'' something which has
never been implemented---just because I'm allowed to contribute to this
``standards'' process? Are you saying that it's okay to ``standardize''
technically inferior solutions---just because I'm allowed to contribute
to this ``standards'' process? Are you saying that it's okay to sidestep
all competition from the free market---just because I'm allowed to
contribute to this ``standards'' process?

Do you truly believe that a hundred people who've never tested their
``informed opinions'' on the market can get together, sit around a
table, and ballot their way to the Holy Grail?

I don't. I want to see POSIX members try their inventions on the real
world. Give yourselves some time to work out the bugs!

> I feel that this is important, because if you
> participated you would know that the process does not work in the
> simplistic (or indeed sinister) way you suggest.

On the contrary. I admire the extent to which ANSI and other standards
committees go to ensure that everyone's opinion is heard. I just can't
believe that we can sit down and write good solutions to problems which
most people have hardly even recognized. Why is POSIX ``standardizing''
printer interfaces? Or protocol-independent networking? Where are the
customer demands for these standards? Is there any indication that more
than a fraction of the computing community has even realized how useful
protocol-independent network interfaces can be? Where's the history of
successes and failures in attacking this problem? Where's the industry
consensus?

Do you really think that you can take any problem in OS design and
figure out a good solution---at least as good a solution as anyone else
will come up with in the foreseeable future? *Any* problem? In other
words, do you really believe that the art of operating systems has
become stagnant?

If so, it's time for POSIX.

If not, then you're inventing and ``standardizing'' poor solutions.

---Dan


Volume-Number: Volume 26, Number 5

From [e-mail]  Thu Nov 21 19:06:30 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09580; Thu, 21 Nov 91 19:06:30 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24096; Thu, 21 Nov 91 19:06:28 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Thu, 21 Nov 1991 21:15:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>The only thing which is perhaps atrocious about "c89" is the name itself. It
>had to be different from "cc"; what would you have chosen?

That's NOT a "given".  It is wrong to think that a UNIX standard would
have to speciay EVERYBODY's options to a standard "cc".  Rather, all
that would be needed in a software portability standard would be the
stuff that virtually every UNIX implementation agrees upon:

    cc -Dmacrostufff -Iheaderdir -c -O foo.c bar.o mylib.a -lX

The requirement that this invocation (when -I etc. aren't being used)
obtain a C implementation that conforms to the C standard could be left
as a separate specification, not necessarily required for 1003.2 proper.

>More than that, regexp's as usually implemented were hopelessly
>ethnocentric; changing languages was impossible.

No, to the contrary the existing regexp implementation was acultural;
you're referring to the idea that "[a-z]" for example ought to mean
"match any lowercase character in the current locale", but that is
NOT what it meant.  It actually meant "match any byte having value
between the values I gave you around the dash-representation" (this
already was important to understand on machines that preferred
EBCDIC codesets, for example).  You should keep in mind that you as
a user are inputting BITS into these patterns, some bytes of which
have special interpretation ([, ^, -, etc.) and others taken
literally as standing for their values.  The ethocentricity was
introduced by 1003.2, presumably because people thought it would be
"nice" to be able to specify locale-dependent character classes; it
did not inhere in the previous regexp mechanism.


Volume-Number: Volume 26, Number 6

From [e-mail]  Fri Nov 22 19:42:41 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12442; Fri, 22 Nov 91 19:42:41 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23863; Fri, 22 Nov 91 19:42:38 -0500
Newsgroups: comp.std.unix
From: Robert Andersson <[e-mail]>
Subject: Standardized X.400 API for UNIX, does one exist?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Gallagher & Robertson A/S
Date: Fri, 22 Nov 1991 15:48:36 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert Andersson)

I've heard rumours that the X/Open group is working on something, possibly
for inclusion into XPG4.  Can anyone confirm/deny this, and perhaps point
me to where the draft standard can be bought?

Thanks in advance, Robert.
--
Robert Andersson    Voice [phone]     Gallagher & Robertson A/S
[e-mail]       Fax   [phone]     Box 1824 Vika, 0123 Oslo, Norway


Volume-Number: Volume 26, Number 7

From [e-mail]  Fri Nov 22 19:42:47 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12482; Fri, 22 Nov 91 19:42:47 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23895; Fri, 22 Nov 91 19:42:44 -0500
Newsgroups: comp.std.unix
From: "Barry E. Hedquist" <[e-mail]>
Subject:  POSIX.2 Validation Suite
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Fri, 22 Nov 1991 17:09:59 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Barry E. Hedquist)

Perennial, Inc., of Santa Clara, CA, announced an Early Access Program
for PVS-2, a Validation Test Suite for POSIX.2 and .2a.  This effort,
already underway, will provide licensees with incremental deliveries of
PVS-2, while it is being developed, at discounted licensing fees.

Perennial is using the Test Environment Toolkit (TET), under joint
development by UNIX International, Open Software Foundation, and X/Open,
as the test harness. The test methods are derived from IEEE Std 1003.3-1991,
and P1003.3.2 Draft 6.  Additional test methods will evolve as P1003.3.2
nears finalization and ballot in mid-1992.

Besides obtaining early access to the test suite, participants
will be provided continuous technical support, and be allowed to
provide technical review of the suite,  on a voluntary basis,
as it is developed.

PVS-2 will cover all testable assertions for POSIX.2 and .2a.
Approximately 5000 assertion are expected for POSIX.2, and another
3500 for POSIX.2a.  By comparison, the PCTS from NIST for POSIX.1-1988
covers approximately 2000 assertions.

Details on this program are available from

    Barry Hedquist
    Perennial
    4699 Old Ironsides Dr. Ste 210
    Santa Clara, CA  95054

    Tel: [phone]
    Fax: [phone]

    internet: [e-mail]
    uucp: uunet!peren!beh


Perennial is the developer of ACVS, the FIPS-160 C Conformance Test Suite
used by the NIST for conformance certification, and several other
commercial test suites for Open Systems Environments, including ANSI/ISO
C, ANSI/ISO C++, UNIX SVR4, BSD 4.3, XPG, and POSIX.1-1990.
Perennial is also a NIST/NVLAP Accredited POSIX Test Laboratory for
FIPS 151-1.

[ Normally, I don't like posting advertisements, but this seemed topical.
  If there is too much of an outcry against it, I won't do it anymore.
  -- mod ]

Volume-Number: Volume 26, Number 8

From [e-mail]  Fri Nov 22 19:43:00 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12552; Fri, 22 Nov 91 19:43:00 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23984; Fri, 22 Nov 91 19:42:56 -0500
Newsgroups: comp.std.unix
From: Bob Lenk <[e-mail]>
Subject: Re: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Fri, 22 Nov 1991 22:31:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:

>    cc -Dmacrostufff -Iheaderdir -c -O foo.c bar.o mylib.a -lX
>
> The requirement that this invocation (when -I etc. aren't being used)
> obtain a C implementation that conforms to the C standard could be left
> as a separate specification, not necessarily required for 1003.2 proper.

Then what use would the 1003.2 spec be?  An application (script/makefile)
using it couldn't depend on it compiling standard C, or K&R C, or 6th
edition C, or perhaps even Cobol.  The separate specification that binds
1003.2 to the C Standard would be required to write portable applications,
and it would have to specify that existing practice be violated.

> >More than that, regexp's as usually implemented were hopelessly
> >ethnocentric; changing languages was impossible.
>
> No, to the contrary the existing regexp implementation was acultural;
> you're referring to the idea that "[a-z]" for example ought to mean
> "match any lowercase character in the current locale", but that is
> NOT what it meant.  It actually meant "match any byte having value
> between the values I gave you around the dash-representation" (this
> already was important to understand on machines that preferred
> EBCDIC codesets, for example).

Now lets look at reality.  How are subranges in regular expressions
really used?  How many scripts have you written that really want to find
all characters with encodings between those of 'a' and 'z'?  How many
scripts have you written that take advantage of the coincidence that
"[a-z]" happens to match "any lowercase character" on an ASCII machine
in an English-speaking country?  Now expand "you" in the previous two
sentences to all users of regular expressions.  How many scripts using
the existing definition work as intended except on an ASCII machine on
English language data?  Do you think regular expressions would have been
developed with this definition on EBCDIC machines or in Denmark or
Japan?  Do you think anyone would have used them if they had been?

IMHO subranges in regular expressions are only interesting, worth
standardizing, or even worth implementing because of the coincidence
that they can be used for concepts like "any lowercase character".  The
people who are happy with the traditional definition are happy because
that coincidence applies with their language and codeset.  Basing an
international standard on this would be not only ethnocentric, but (as
Doug helps to point out) codeset-centric as well.

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


Volume-Number: Volume 26, Number 9

From [e-mail]  Sat Nov 23 19:41:47 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12878; Sat, 23 Nov 91 19:41:47 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19149; Sat, 23 Nov 91 19:41:45 -0500
Newsgroups: comp.std.unix
From: Robert Makowski <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Sat, 23 Nov 1991 21:51:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert Makowski)

On  21 Nov 91 01:07:51 GMT,  [e-mail] (Dan Bernstein) said:
> Randall Howard writes:
> > Dan, you've missed the most important thing that differentiates a
> > consensus based standards process like the IEEE, ANSI, and ISO (i.e.
> > POSIX) from vendor or consortia-based standards like SVID or SVR4.
> > That point is that you, and everyone else, are allowed to both
> > participate in the working group that created the standard and to
> > ballot on the result produced by that working group.
>
> So what?
>
> Are you saying that it's okay to ``standardize'' something which has
> never been implemented---just because I'm allowed to contribute to this
> ``standards'' process? Are you saying that it's okay to ``standardize''

I guess can't see the connection from Randall's reply. His
addressed your concerns about dictators, albeit I'm not sure if you
originally meant in Posix or in the "standard source consortia". I think
Randall's reply is correct, the IEEE process "open" when compared to a
consortium. There, you've got to work for an X/Open, UI, OSF, Ace boss
to play in the std source arena.

(IMHO, though, I do think that POSIX historically suffers from the
"some are more equal" syndrome.  The best thing is real live user
participants who have only technical agendas,  but until stds are done
via e-mail [which BTW I've proposed in a TCOS ballot] only the COs
involved can afford to pay the air fare.  That's why I always thought
that "stds body" competition levels the playing field *somewhat*.  )

> technically inferior solutions---just because I'm allowed to contribute
> to this ``standards'' process? Are you saying that it's okay to sidestep
> all competition from the free market---just because I'm allowed to
> contribute to this ``standards'' process?

As to the "junk stds" sentiment, I didn't think that had anything to
do with Randalls reply. But ... Now that you mention it, posix
"solutions" aren't solutions, they're interfaces and semantics. In
the core group of posix groups, these interfaces are documenting
existing practise, other groups I'm not so sure. I do know that in
P.2, some things were invented because there were too many religious
fights over "inferior" solutions. (E.g., pax(1) vs. tar(1) vs.
cpio(1) wars.) The same thing happened in P.1.

>
> Do you truly believe that a hundred people who've never tested their
> ``informed opinions'' on the market can get together, sit around a
> table, and ballot their way to the Holy Grail?
>
> I don't. I want to see POSIX members try their inventions on the real
> world. Give yourselves some time to work out the bugs!

Here, I disagree with the premises. Randall is an excellent counter
example to the assertion that posix is done in an experiencal vacuum. He
and his coworkers personally implement stds, and I can't think of anyone
I've met at posix who weren't in the same class. And, I know of several
examples where new ideas were "tested", usually in incredibly short time.

>
> > I feel that this is important, because if you
> > participated you would know that the process does not work in the
> > simplistic (or indeed sinister) way you suggest.
>
> On the contrary. I admire ...
> ...Why is POSIX ``standardizing''
> printer interfaces? Or protocol-independent networking? Where are the
> customer demands for these standards? ...
> ...Where's the industry consensus?

Well, by definition, IEEE standards are representations of an
industry consensus, and there's a well formed system for building
that consensus.  Yet, I can understand your frustration. I'm not
convinced that all the existing posix work is viable, but I figure
that I'm just not interested personally in some of these groups. In
any case, I fully expect that if there wasn't money out there, a
company wouldn't altruistically participate.

>
> ...
> words, do you really believe that the art of operating systems has
> become stagnant?

I know there're many who believe standards mean stagnation, and that's
not true either. Human communication needs language standards, but these
are just tools to express ideas. I regard computer stds the same way.

= Bob (mak) Makowski

CO:        MacDonald Dettwiler Associates, Richmond, B.C.
INTERNET:    [e-mail]
VOICE:        604-278-3411 x 2865
FAX:        [phone]

Volume-Number: Volume 26, Number 10

From [e-mail]  Sat Nov 23 19:41:50 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12885; Sat, 23 Nov 91 19:41:50 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19156; Sat, 23 Nov 91 19:41:48 -0500
Newsgroups: comp.std.unix
From: Robert Makowski <[e-mail]>
Subject: Re: intl RE [Was: VR4 comply with P1003.2?]
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Sat, 23 Nov 1991 21:59:28 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert Makowski)

On  21 Nov 91 21:15:00 GMT,  [e-mail] (Doug Gwyn) said:
> Submitted-by: [e-mail] (Doug Gwyn)
>
> No, to the contrary the existing regexp implementation was acultural;
> you're referring to the idea that "[a-z]" for example ought to mean
> "match any lowercase character in the current locale", but that is
> NOT what it meant.  It actually meant "match any byte having value
> between the values I gave you around the dash-representation" (this
> ... The ethocentricity was
> introduced by 1003.2, presumably because people thought it would be
> "nice" to be able to specify locale-dependent character classes; it
> did not inhere in the previous regexp mechanism.
>
> ----- End of Excerpt  [e-mail] (Doug Gwyn)

Actually, it was not introduced by 1003.2, it was introduced by [nee]
/usr/group's Internationalization Working Group at the SLC '87 meeting.
I know, I hosted the meeting and was a party thereof.

BTW, the 1003.2 connection is that p1003.2's PAR included
internationalization requirements, for much the same reason as p1003.1.
These ieee stds are all ISO inputs, and that's where the requirements
originated.

= Bob (mak) Makowski

CO:        MacDonald Dettwiler Associates, Richmond, B.C.
INTERNET:    [e-mail]
VOICE:        604-278-3411 x 2865
FAX:        [phone]

Volume-Number: Volume 26, Number 11

From [e-mail]  Sun Nov 24 15:48:56 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04682; Sun, 24 Nov 91 15:48:56 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14361; Sun, 24 Nov 91 15:48:52 -0500
Newsgroups: comp.std.unix
From: Jason Zions <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard,     Information Networks Group
Date: Sun, 24 Nov 1991 19:30:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Do you truly believe that a hundred people who've never tested their
>``informed opinions'' on the market can get together, sit around a
>table, and ballot their way to the Holy Grail?

I'm getting really tired of this baseless accusation. Come to a meeting; ask
the people there, who are employed by vendors, if they implement the stuff
they're standardizing. The numbers will surprise *you*; they'll surprise
almost no one else.

>Why is POSIX ``standardizing'' printer interfaces?

Well, because you can't sell a system today that supports neither SysV lp or
BSD lpr; that seems to indicate the market has settled on a couple of nearly
universally reviled standards. You might ask the Palladium gang from
MIT-Athena about the degree of interest in their stuff. You might check
around at the number of implementations of it. Lots and lots of
implementation experience, just what you want to see.

>Or protocol-independent networking?

Because you can't sell a system today that supports neither (SysV TLI or
X/Open XTI) or BSD sockets. Because the clamor to standardize *both* of
them, or just *one* of them, is deafening. Lots and lots of implementation
experience, just what you want to see.


> Where are the customer demands for these standards?

Tell me - would you buy a system that didn't support Berkeley lpr and
sockets? If you're a SVR4 kinda guy, would you buy a system that failed to
support lp and TLI/XTI? *That* is customer demand.

>Is there any indication that more
>than a fraction of the computing community has even realized how useful
>protocol-independent network interfaces can be? Where's the history of
>successes and failures in attacking this problem? Where's the industry
>consensus?

The early revisions of XTI, the early history of TLI, the Tahoe and Reno
versions of OSI sockets; and those are just the very well known ones.

>If not, then you're inventing and ``standardizing'' poor solutions.

Dan, sad to say, if one talks to a large number of users, one often hears
the phrase "better a bad standard, or two weak conflicting standards, than
no standard at all." I may disagree with that sentiment, but I have heard it
expressed many times. As for the solutions being poor, I happen to disagree
with you there; many of them are *different* from what you might think are
good solutions, but few of them are demonstrably poorer, and many of them
are demonstrably better against the set of criteria POSIX has to deal with.

Finally, I think the fact that POSIX standards are continually being issued,
being revised, and that there is every expectation that this will continue
into the future for quite a ways, is some proof against the ossification of
the state of the art through standardization.

When's the last time you've been to a POSIX meeting, Dan? Perhaps you might
want to come down and watch the sausage being made; the rules they play by
address many of your concerns.

DISCLAIMER: All opinions contained herein are mine. I do not claim to
represent in any way IEEE-CS TCOS-SS, the TCOS-SS SEC, any subcommittee
thereof, or and working group under the auspices of IEEE-CS TCOS-SS. I am
involved with POSIX standardization, but cannot speak on behalf thereof.

Jason Zions
Chair, IEEE P1003.8
[e-mail]

Volume-Number: Volume 26, Number 12

From [e-mail]  Sun Nov 24 16:38:07 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05359; Sun, 24 Nov 91 16:38:07 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17441; Sun, 24 Nov 91 16:38:04 -0500
Newsgroups: comp.std.unix
From: Sean Eric Fagan <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Kithrup Enterprises, Ltd.
References: <[e-mail]>
Date: Sun, 24 Nov 1991 21:08:48 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>I'm getting really tired of this baseless accusation. Come to a meeting; ask
>the people there, who are employed by vendors, if they implement the stuff
>they're standardizing. The numbers will surprise *you*; they'll surprise
>almost no one else.

Having worked at a company that implemented some POSIX features during and
after the standardisation process, I know what Dan's saying:  some of the
things being standardised did not exist until POSIX invented them.  POSIX
job control, Dan's personal favorite, is similar, but not quite like, BSD
job control, which everyone else used.

Since it did not exist until POSIX invented it, how could it managed to have
been tested before it was standardised (and, due to FIPS, required for
certain key sales)?  There is a difference between standardising what you
have implemented, and implementing what you have standardised.

--
Sean Eric Fagan
[e-mail]

Volume-Number: Volume 26, Number 13

From [e-mail]  Sun Nov 24 19:36:04 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07668; Sun, 24 Nov 91 19:36:04 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00228; Sun, 24 Nov 91 19:36:02 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: POSIX vs. practical experience
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Mon, 25 Nov 1991 00:05:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (Jason Zions)
>>Do you truly believe that a hundred people who've never tested their
>>``informed opinions'' on the market can get together, sit around a
>>table, and ballot their way to the Holy Grail?
>
>I'm getting really tired of this baseless accusation. Come to a meeting; ask
>the people there, who are employed by vendors, if they implement the stuff
>they're standardizing. The numbers will surprise *you*; they'll surprise
>almost no one else.

They may not surprise him if he asks the right questions.  Like, for
example, "how many people here have implemented 1003.2 regular expressions
from scratch straight from the spec?".  Based on the number of problems I
found in the spec when I did the syntactic part of this a couple of months
ago, I am quite certain that none of the people involved had ever tried it.
I found, and reported, half a dozen serious problems in a spec that was
supposed to be very near its final state.  And this, mind you, was in
a fairly well-understood area with a lot of existing practice to draw on.

This accusation, I'm afraid, is *not* baseless.  Those people are not
implementing the stuff they are standardizing; they are implementing their
own interpretation of the important parts of what they think it says.
They are in for a very nasty shock when their customers start reading
the fine print and demanding that they comply with it.  Hell, *I* thought
the 1003.2 regexp stuff was fine -- I wrote some of it! -- until I tried
implementing it solely from the draft standard.
--
SVR4:  the first system so open that    | Henry Spencer @ U of Toronto Zoology
everyone dumps their garbage there.     |  [e-mail]  utzoo!henry


Volume-Number: Volume 26, Number 14

From [e-mail]  Mon Nov 25 00:43:19 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12350; Mon, 25 Nov 91 00:43:19 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21233; Mon, 25 Nov 91 00:43:16 -0500
Newsgroups: comp.std.unix
From: "Scott E. Preece" <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Motorola MCD, Urbana Design Center
References: <[e-mail]> <[e-mail]>
Date: Mon, 25 Nov 1991 05:21:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scott E. Preece)

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

| Having worked at a company that implemented some POSIX features during and
| after the standardisation process, I know what Dan's saying:  some of the
| things being standardised did not exist until POSIX invented them.  POSIX
| job control, Dan's personal favorite, is similar, but not quite like, BSD
| job control, which everyone else used.
|
| Since it did not exist until POSIX invented it, how could it managed to have
| been tested before it was standardised (and, due to FIPS, required for
| certain key sales)?  There is a difference between standardising what you
| have implemented, and implementing what you have standardised.
---
Yes, but the working group is supposed to be made up of people who
have a lot of experience with the existing art and its implementation
and know (1) what is implementable and (2) what is wrong with the
existing art.  There are enough people involved with an interest in
continuing to sell what already exists that people have to be able to
produce serious arguments (which would translate into responsive
negative ballots) to effect a change.  Usually this means there is
consensus in the group that there are serious problems with existing
approaches *and* there is consensus in the group that the functionality
can't just be left out of the standard *and* what is proposed is similar
enough to existing approaches that the experienced implementors in the
group believe implementation is practical.

Also, of course, it's a long time from the appearance of an interface in
a draft standard to the time the standard completes balloting and is
approved.  In that time people generally do do prototype implementations
to validate their expectations.

While it's almost always better to standardize existing practice than
invent new solutions, there are elements of existing systems that are
universally rejected as inadequate, broken, or mistaken, and it would be
a disservice to the community to standardize things that the group
consensus recognized as bad practice.


--
scott preece
motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]

Volume-Number: Volume 26, Number 15

From [e-mail]  Mon Nov 25 13:45:28 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26072; Mon, 25 Nov 91 13:45:28 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24205; Mon, 25 Nov 91 13:45:24 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Re: Inventing standards
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 25 Nov 1991 13:18:37 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

>Why is POSIX ``standardizing'' printer interfaces?

% Well, because you can't sell a system today that supports neither
% SysV lp or BSD lpr; that seems to indicate the market has settled on a
% couple of nearly universally reviled standards. You might ask the
% Palladium gang from MIT-Athena about the degree of interest in their
% stuff. You might check around at the number of implementations of it.
% Lots and lots of implementation experience, just what you want to see.

Palladium is NOT widely implemented outside MIT.

  As you yourself indicate, the demand is for EXISTING PRACTICE
(either BSDish or SVIDish) and so of course POSIX will standardise
NEITHER and instead standardise a technology which is not widely
implemented in existing UNIX systems or most anywhere else outside of
MIT.

  They also are planning to standardise none of the usual existing
printer user commands (lpadmin/lpstat/lpr/lpq) which is also baffling,
especially since lp(1) _IS_ standardised by POSIX.2 and so different
parts of POSIX will have incompatible user portability impairing
characteristics.  Moreover, standardising the user interface doesn't
restrict the underlying mechanism used to implement printers and
queues so even the proprietary vendors haven't much room to gripe.

  Moreover, there is no apparent effort to standardise the printer
networking protocol which is required for interoperability.  Note
that a recent Internet RFC provides a public specification for the
lpr protocol finally.

  The bottom line is that IF an area is to be standardised, existing
practice is what should be in the standard.

  TLI/XTI has always had protocol-independent networking as an
objective, so the desire of POSIX to standardise this is more easily
understood.  The key question is whether they will standardise
existing practice (sockets and XTI/TLI) or whether they will go out
and standardise some other new technology.  I hope to see sockets and
TLI come out of the process, if anything at all.

> Where are the customer demands for these standards?

% Tell me - would you buy a system that didn't support Berkeley lpr and
% sockets? If you're a SVR4 kinda guy, would you buy a system that
% failed to support lp and TLI/XTI? *That* is customer demand.

See comments above.  Note that lpr is NOT being standardised; POSIX.2
went with lp instead (which is fine since lp is also existing practice).

%  As for the solutions being poor, I happen to disagree with you
% there; many of them are *different* from what you might think are good
% solutions, but few of them are demonstrably poorer, and many of them
% are demonstrably better against the set of criteria POSIX has to deal
% with.

POSIX should not standardise anything that isn't widespread existing
practice.  Palladium is an excellent of precisely what it should not
standardise because it isn't existing practice in historical systems.

%  When's the last time you've been to a POSIX meeting, Dan? Perhaps
% you might want to come down and watch the sausage being made; the
% rules they play by address many of your concerns.

  Most mere mortals cannot afford to wander around the globe with air
fare and hotel costs.  What us mere mortals can do (and at least some
of us try to do) is to vote down the more outrageous inventions and
object to some of the omissions when the draft hits balloting.  Even
then it doesn't always work.

  For example, I really see a need for users to be able to give
file(1) hints about new file types using the traditional, historical,
well-understood option.  The committee has for 3 rounds insisted on
misinterpreting my objection as demanding that file(1) _always_ use a
"magic" file when my objection has said that the use of a "magic" file
or any other mechanism to give file(1) hints on new file types.  The
committee says that since I can't know all of the file types on all
systems in the world that _NO_ extensibility mechanism is
standardisable.  I think their argument merely confirms my assessment
that some mechanism to allow users to give hints to file(1) is
absolutely necessary.  Existing UNIX systems vendors all include
file(1) and even the MKS folks include it for PCs (meaning that no
effort would be required to implement the proposed option, so I
speculate that it is a large vendor known for its proprietary OS that
is behind this particular nonsense.

  Another example, I had several objections to POSIX.2 specs that were
written in a way that was needlessly strict and meant that no trusted
system could conform.  Some of these were accepted and the text
rephrased, but others were rejected for reasons that remain unclear.
In this case, it turns out that the POSIX.6 group is going to modify
the semantics of the POSIX.2 draft in order to fix these, so the
POSIX.2 draft will be modified (fixed) by the POSIX.6 ballot (which is
currently out for review).

  The bottom line is that users are really coming out on the short end
of the stick in this process because of the many places where POSIX is
inventing or adopting new technology to standardise despite the
existance of mechanisms in BSD, SVID, or shared by both.  In
particular, people who do attend committee meetings keep telling me
that vendors of proprietary systems repeatedly try to get the
standards watered down so that their existing closed system can be
marketed as POSIX-conforming or try to ensure that the existing
practices are rejected for standardisation so that the open vendors
are penalised.

Randall Atkinson
[e-mail]

DISCLAIMER:
Views belong to the author, not necessarily his employer.

P.S.
  Commercial announcements and such like create problems for many
sites, particularly government sites which are under strict "no
commercial use" rules.  If commercial announcements continue to be
made to the comp.std.unix list, there is the possibility that USENET
newsfeeds of the group will have to be dropped at a number of sites.
This has happened at some agencies in the past and is a very real
problem that is normally handled by the affected agencies by not
carrying comp.newprod and any other group which has commercial
traffic.  I'm not sure what NRL policy is on this, but I do know that
it is true at a number of other sites both government and commercial.


Volume-Number: Volume 26, Number 16

From [e-mail]  Mon Nov 25 13:45:32 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26079; Mon, 25 Nov 91 13:45:32 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24227; Mon, 25 Nov 91 13:45:30 -0500
Newsgroups: comp.std.unix
From: John F Haugh II <[e-mail]>
Subject: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: John F Haugh II <[e-mail]>
X-Submissions: [e-mail]
Organization: Somewhere in Simpson Bay, Sint Maarten, Nederland Antilles
References: <[e-mail]> <[e-mail]>
Date: Mon, 25 Nov 1991 14:23:11 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>No, to the contrary the existing regexp implementation was acultural;
>you're referring to the idea that "[a-z]" for example ought to mean
>"match any lowercase character in the current locale", but that is
>NOT what it meant.  It actually meant "match any byte having value
>between the values I gave you around the dash-representation" (this
>already was important to understand on machines that preferred
>EBCDIC codesets, for example).  You should keep in mind that you as
>a user are inputting BITS into these patterns, some bytes of which
>have special interpretation ([, ^, -, etc.) and others taken
>literally as standing for their values.  The ethocentricity was
>introduced by 1003.2, presumably because people thought it would be
>"nice" to be able to specify locale-dependent character classes; it
>did not inhere in the previous regexp mechanism.

I would say that POSIX completely ignored any codeset which was not
7-bit clean ASCII.  The simple issue of 8-bit code points being
mangled by ISTRIP is clear proof of this point.  The definition of
this function is in terms of bit widths, rather than character sizes.
Any 8-bit code set (such as the European character sets or even EBCDIC)
are mangled by the translation suggested by ISTRIP.

I am certain that the various groups did give some thought to the
issue, but it really is pretty obvious that 1003.1 completely ignored
any system which uses 8 bit character sets.

While 1003.1 was off inventing a new tty subsystem, it would have
been nice if they invented an interface for setting any locale-specific
traits of the tty system (a "tcsetlocale()" sort of deal) that would
provide for translations of locale-specific characters (the variously
accented vowels, for example) into something more POSIX-friendly.
--
John F. Haugh II        |I am the NRA.     | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] |Take a friend shooting.| Domain: [e-mail]
" ... expectation is the mother of disappointment."
        -- Brad Konopik

Volume-Number: Volume 26, Number 17

From [e-mail]  Mon Nov 25 15:45:28 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07052; Mon, 25 Nov 91 15:45:28 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01488; Mon, 25 Nov 91 15:45:25 -0500
Newsgroups: comp.std.unix
From: Steve Correll <[e-mail]>
Subject: Re: POSIX vs. practical experience
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Borland International
References: <[e-mail]> <[e-mail]>
Date: Mon, 25 Nov 1991 20:02:34 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Steve Correll)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>..."how many people here have implemented 1003.2 regular expressions
>from scratch straight from the spec?".  Based on the number of problems I
>found in the spec when I did the syntactic part of this a couple of months
>ago, I am quite certain that none of the people involved had ever tried it.
>I found, and reported, half a dozen serious problems in a spec that was
>supposed to be very near its final state.  And this, mind you, was in
>a fairly well-understood area with a lot of existing practice to draw on.

Perhaps Unix is none of my business, but people in the Fortran community have
just watched the ANSI X3J3 committee make the mistake of standardizing a
painstakingly designed but unimplemented language, and consequently the
Fortran 90 standard is full of outright bugs and missing provisions.

For example, Fortran 90 introduces a construct which is comparable to a C
prototype declaration. One would like to write a tool which would generate
such prototypes automatically for every Fortran procedure, which would be much
less error-prone than generating prototypes by hand or doing without them.

If someone had actually written such a program and tried it out on real,
existing applications prior to adoption of the standard, they would have
immediately found a bug in the standard which for certain procedures makes it
impossible to write a legal prototype at all.

Unless you believe that a sufficiently large group of programmers can write
bug-free programs without ever testing them, it's folly to write a standard
without testing it. Specifications of standards are, if anything, harder to
write than actual programs.

I think one of the greatest strengths of the ANSI C committee was its
reluctance to incorporate new features unless somebody could point to an
existing implementation with a history of user satisfaction.


Volume-Number: Volume 26, Number 18

From [e-mail]  Tue Nov 26 18:41:31 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00129; Tue, 26 Nov 91 18:41:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12492; Tue, 26 Nov 91 18:41:28 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 26 Nov 1991 18:23:59 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
>I would say that POSIX completely ignored any codeset which was not
>7-bit clean ASCII.  The simple issue of 8-bit code points being
>mangled by ISTRIP is clear proof of this point.  The definition of
>this function is in terms of bit widths, rather than character sizes.
>Any 8-bit code set (such as the European character sets or even EBCDIC)
>are mangled by the translation suggested by ISTRIP.
>
>I am certain that the various groups did give some thought to the
>issue, but it really is pretty obvious that 1003.1 completely ignored
>any system which uses 8 bit character sets.
>
>While 1003.1 was off inventing a new tty subsystem, it would have
>been nice if they invented an interface for setting any locale-specific
>traits of the tty system (a "tcsetlocale()" sort of deal) that would
>provide for translations of locale-specific characters (the variously
>accented vowels, for example) into something more POSIX-friendly.

How utterly off the mark can you be?  ISTRIP was not a POSIX invention;
it was existing practice, as was the entire 8-bit byte orientation of
the terminal device support (parity bits etc.)  If you need all 8 data
bits for your terminal connection then simply don't specify ISTRIP to
the terminal handler.  Unlike V7/BSD tty handlers that discard input
when switching canonicalization modes, the 1003.1 model (like UNIX
System V) doesn't demand such input flushing, making it suited just
fine to a multibyte environment.  Keep in mind that multibyte characters
are required by higher-level standards and conventions to be provided
as byte streams, not single-text-character-representation chunks.  There
could obviously be surprising effects when, for example, the user is
trying to "erase" a just-typed text-character, not just the final byte
of it, if the terminal handler does not understand the intention of the
"erase" function, but that need to be dealt with at a lower level than
the application/OS interface that 1003.1 specifies.

The 1003.1 terminal control functions are simply an interface to the
underlying primitive operations provided by existing or future
implementations, primarily those from UNIX System V augmented somewhat
by support for BSD tty features.  The original draft 1003.1 had
specified these as ioctl()s along the lines of existing practice,
slanted toward the System V specifics with a few tweaks to accommodate
BSD extensions (as opposed to being based on the V7/BSD tty ioctl()s).
While that was the right blend of functionality, there were two main
objections.  (1) It meant either wedging a separate-but-equal tty
interface into the OS "kernel", which is effectively what a later
release of BSD went ahead and did, or else "layering" an emulation of
the POSIX ioctl() behavior around an existing but different tty ioctl(),
along the lines of the BRL UNIX System V emulation for 4BSD.  People
weren't terribly happy with either option.  (2) Handling terminal
behavior via bit vectors and ioctl()s is awkward and error-prone; few
applications I have seen get this entirely right.  Interfaces to allow
the programmer to more directly and cleanly specify the desired actions
are clearly needed, and since they didn't exist as part of existing
commercial UNIX systems (every application programmer ended up rolling
his own), devising a standard interface for this widely-but-varyingly-
implemented facility was a positive service to the programmer.  There
is nothing preventing you from continuing to use your existing kludges
instead of the POSIX standard terminal control interface, but as a
matter of improved portability you should probably change your local
kludges to match the POSIX interface and use the vendor-provided
version when it exists instead of replacing it with yours.  In the
long run that should mean that you can stop having to deal with tty
variations when porting software.

In summary, I think 1003.1 addressed the terminal control functionality
sensibly and responsibly, and that there is no need for it to address
the kinds of things that you seem to be talking about.


Volume-Number: Volume 26, Number 20

From [e-mail]  Tue Nov 26 18:41:34 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00134; Tue, 26 Nov 91 18:41:34 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12507; Tue, 26 Nov 91 18:41:30 -0500
Newsgroups: comp.std.unix
From: Donald Lewine <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Data General Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Tue, 26 Nov 1991 16:44:22 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]>, [e-mail] (John F Haugh II) writes:
|>
|> I would say that POSIX completely ignored any codeset which was not
|> 7-bit clean ASCII.  The simple issue of 8-bit code points being
|> mangled by ISTRIP is clear proof of this point.  The definition of
|> this function is in terms of bit widths, rather than character sizes.
|> Any 8-bit code set (such as the European character sets or even EBCDIC)
|> are mangled by the translation suggested by ISTRIP.
POSIX.1 supports ISTRIP because it was historically present in the
reference systems.  Supporting the flag is consistent with the goal
of breaking as few applications as possible.  POSIX.1 Section B.7.1.2.2
states, "Although the ISTRIP flag is normally superfluous with today's
terminal hardware and software, it is historically supported. Therefore,
applications may be using ISTRIP, and there is no technical problem with
supporting this flag."  I could add that removing the ISTRIP flag would
not cause any of those applications to instantly start supporting
European character sets or EBCDIC.  Leaving the flag in the standard
does not indicate any bias by the committee or the IEEE.

|>
|> I am certain that the various groups did give some thought to the
|> issue, but it really is pretty obvious that 1003.1 completely ignored
|> any system which uses 8 bit character sets.
|>
|> While 1003.1 was off inventing a new tty subsystem, it would have
|> been nice if they invented an interface for setting any locale-specific
|> traits of the tty system (a "tcsetlocale()" sort of deal) that would
|> provide for translations of locale-specific characters (the variously
|> accented vowels, for example) into something more POSIX-friendly.
They left all of hooks to add locale-specific processing:
 7.1.2.1: The members of the [termios] structure are not limited to
          those shown it Table 7-1.
 7.1.1.9: An implementation may define multibyte sequences that have
          a meaning different from the meaning of the bytes when
          considered individually.  Implementations may also
          define additional single-byte functions.
 7.1.2.5: If IEXTEN is set, implementation-defined functions shall be
          recognized from the input data.
 B.7 (4): None of the basic historical implementations are adequate
          in an international environment.  This concern is not
          technically within the scope of POSIX.1, but the goal of
          POSIX.1 was to mandate no unnecessary impediments to
          internationalization.
 B.7.2:   Applications should always do a tcgetattr(), save the
          termios structure values returned, and then do a
          tcsetattr() changing only the necessary fields [thus
          preserving all implementation-defined flags].

In short, my reading of POSIX.1 shows that there was a great deal of
concern with internationalization and that the inclusion of ISTRIP is
not "clear proof" that "POSIX ignored any codeset which was not
7-bit clean ASCII."

--------------------------------------------------------------------
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 26, Number 19

From [e-mail]  Tue Nov 26 18:41:45 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00159; Tue, 26 Nov 91 18:41:45 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12538; Tue, 26 Nov 91 18:41:39 -0500
Newsgroups: comp.std.unix
From: Duke Robillard <[e-mail]>
Subject: Excerpt from minutes of POSIX 1003.7a, the Printing Small Group
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Bellcore, Piscataway, NJ
Date: Tue, 26 Nov 1991 22:48:12 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Duke Robillard)

                    Excerpts from
POSIX 1003.7a Printing Small Group Minutes, October 21-24, 1991

..

The meeting started with a review of last quarter's work.
At the last meeting, the functionality of Palladium and lp
CLI's was merged into a new set of commands, all starting
with the prefix "xp."  This work was brought into question.
There were concerns that POSIX shouldn't invent new interfaces.
The widespread acceptance of OSF's DME product, including USL's
recent announcement regarding the ACE iniative seemed to
mitigate the concern about Palladium's limited distribution,
since it is part of DME.  This facts, along with the lack
of an advocate for lp, led to the abandonment of the xp
commands and a return of Palladium's pd commands.

If 1003.7a is going to meet its ballot date goals, the quesion
of whether to use lp, pd, a new command set, or some mixture of
these must be decided for the final time at the next meeting.
The printing small group urges anyone with an interest in this
to come to Irvine, California for the January 13-17 POSIX
meeting, or to send written proposals or arguments.

..

The next debate was about which API to use.  There was some
discussion about adopting Tivoli's "objcall" interface from
the DME.  No one was very familiar with it, but it seemed to
be a lower level interface, designed for general object management
rather than printing.  Since the SVR4's lp system doesn't have an
API, this was really a debate about which level of Palladium API
to use.

..

The high-level interface ("API") was eliminated first, because of its
limited value added over just calling the CLI.  The low-level interface
("pdlib + RPC/IDL") was also elimnated because of its close ties to a
specific RPC mechanism.  The middle-level interface ("SPI") was selected.
It allows developers to write new CLIs and GUIs, but is still manipulating
the ISO print objects.  This interface won't insure interoperability, but
1003.7 is counting on its managed object definitions to do that.

..

        Items for the Agenda of the January 13-17 Meeting

    Which command set: pd*, lp*, or some mix.  A debate & vote
    Monday during the 1003.7 plenary.

    Review and update CLI section of draft, particularly rationale
    & test assertions.  Decide on required vs optional commands

    Review and update SPI section of draft.  Work on SPI
    test assertions.

    Address 1003.6 (POSIX Security) concerns.

    Address Internationalization concerns.

    Additions to ISO Print Objects

+---------------------------------------------------------------------+
|  Bob Robillard, Technical Editor, P1003.7     Bellcore              |
|  [e-mail]                   RRC 1D-229            |
|  bcr!pyuxv!duke                               444 Hoes Lane         |
|  908-699-2249, FAX: [phone]              Piscataway, NJ 08854  |
+---------------------------------------------------------------------+

aka
Duke Robillard                              DoD #0130
Internet:   [e-mail]
USENET:     {backbone}!bcr!pyuxv!duke


Volume-Number: Volume 26, Number 21

From [e-mail]  Wed Nov 27 13:17:25 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10486; Wed, 27 Nov 91 13:17:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11513; Wed, 27 Nov 91 13:17:22 -0500
Newsgroups: comp.std.unix
From: John F Haugh II <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: John F Haugh II <[e-mail]>
X-Submissions: [e-mail]
Organization: Somewhere in Simpson Bay, Sint Maarten, Nederland Antilles
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 27 Nov 1991 14:53:16 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>How utterly off the mark can you be?  ISTRIP was not a POSIX invention;
>it was existing practice, as was the entire 8-bit byte orientation of
>the terminal device support (parity bits etc.)  If you need all 8 data
>bits for your terminal connection then simply don't specify ISTRIP to
>the terminal handler.

I'll start with just my remarks regarding ISTRIP since they seem to have
generated the most heat.

It was not my intention to claim that POSIX invented ISTRIP, indeed,
they did not - it's mentioned in my System V manual which predates the
notion of POSIX by several years.  Rather, it is my claim that ISTRIP
is required to be supported and that if you support it as described
by the standard, then 8 bit code sets will be destructively translated
on input.  Furthermore, the recovery from such an event is non-trivial
(that is, you can't just turn parity on for your TTY device and make
it work correctly.) for the end user.

As an example, EBCDIC has its characters spread throughout the entire
8 bit range.  If ISTRIP should become turned on, the translation
of the EBCDIC character 'a' would be from 0x81 to 0x01, and for 'A'
it would be from 0xC1 to 0x41.  While the response is often "Don't
do that then", the complaint which I have is that POSIX could have
had the foresight to 1) not require ISTRIP be supported for all
asynchronous hardware interfaces (that is, it becomes implementation
defined as to being supported or not) 2) defined it in terms of the
size of the character being received (that is, "cs7" would mean
"strip to 7 bits" and "cs8" would mean "strip to 8 bits") or 3)
something completely different.  I tend to prefer 1) since 7.1.2.4
defines parity, and it seems ISTRIP is really a parity and word-size
issue.

Both the Rationale and 7.1.2.2 explicitly refer to 7 bit characters
"which are common".  Anyone who has worked with characters from the
international character sets is aware that outside of these United
States, 8 bit characters "are common".  There is no room to change
ISTRIP to be more meaningful in the environment which it exists in
because the standard has explicitly stated that it must exist, and
that it must behave in a specific fashion.

>                                            (2) Handling terminal
>behavior via bit vectors and ioctl()s is awkward and error-prone; few
>applications I have seen get this entirely right.  Interfaces to allow
>the programmer to more directly and cleanly specify the desired actions
>are clearly needed, and since they didn't exist as part of existing
>commercial UNIX systems (every application programmer ended up rolling
>his own), devising a standard interface for this widely-but-varyingly-
>implemented facility was a positive service to the programmer.  There
>is nothing preventing you from continuing to use your existing kludges
>instead of the POSIX standard terminal control interface, but as a
>matter of improved portability you should probably change your local
>kludges to match the POSIX interface and use the vendor-provided
>version when it exists instead of replacing it with yours.  In the
>long run that should mean that you can stop having to deal with tty
>variations when porting software.

This touches on part of my complaint.  By specifying ISTRIP in the
manner which it has been described, a portable application can never
use it since that application is never assured of knowing the size
of its input characters (that is, 7 bits or 8).  It really is an
implementation defined function that the implementation should have
been allowed to control more to its liking.  If, as the Rationale
says "Although the ISTRIP flag is normally superfluous in today's
terminal hardware and software", why is it a required feature?  As
an example of where POSIX is more to my liking, 7.1.2.4 allows the
implementor the decency of not supporting 5, 6, or 7 bit characters
where the underlying hardware may not support such (or even where
it just may not make sense).

>In summary, I think 1003.1 addressed the terminal control functionality
>sensibly and responsibly, and that there is no need for it to address
>the kinds of things that you seem to be talking about.

Perhaps from a US-centric perspective there isn't - 7 bit ASCII is
the predominant code set, but as POSIX-like operating systems make
their way to Europe and beyond, this conflict between 7 bit and
8 bit code sets will become more evident.

The question which needed to be asked is "What happens if I take
an 8 bit character and process it with a POSIX compliant terminal
interface?"  Which brings up my question, given that ISTRIP must
behave according to the specification, how can I support it in an
environment where 8 bit characters are common?  The answer is I
can't and it is completely meaningless to do so - and there, but
for the grace of POSIX go I ...

I can appreciate the statement that the programmer should only
change those bits which are relevant or needed, but as Doug states
above, controlling terminal modes with a collection of bit vectors
is prone to error.  The end user will not care where the problem
lies, only that there is one.  I think that Vince Lombardi said
"By failing to prepare, you are preparing to fail."  This sums it
up - there is no graceful path for non-7-bit character sets to
be supported via that is not "error-prone".
--
John F. Haugh II        |I am the NRA.     | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] |Take a friend shooting.| Domain: [e-mail]
" ... expectation is the mother of disappointment."
        -- Brad Konopik


Volume-Number: Volume 26, Number 22

From [e-mail]  Wed Nov 27 14:36:00 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04811; Wed, 27 Nov 91 14:36:00 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00920; Wed, 27 Nov 91 14:35:58 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 27 Nov 1991 18:39:25 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (John F Haugh II)
>... Which brings up my question, given that ISTRIP must
>behave according to the specification, how can I support it in an
>environment where 8 bit characters are common?  The answer is I
>can't and it is completely meaningless to do so ...

Certainly you can support it, in the same way that most Unix systems
support delay options for Teletype Model 37 printing terminals even
though no Model 37s are in use with those systems or ever will be.
It may be useless in your environment, but you can always continue
to support it.

>I can appreciate the statement that the programmer should only
>change those bits which are relevant or needed, but as Doug states
>above, controlling terminal modes with a collection of bit vectors
>is prone to error.  The end user will not care where the problem
>lies, only that there is one.

If ISTRIP was the only bit that could foul up user terminal input, this
might be a telling argument.  It's not, so this is a ridiculous argument.
Changing random bits in the terminal mode is *almost guaranteed* to cause
trouble.  Eliminating ISTRIP would not change that.

>... If, as the Rationale
>says "Although the ISTRIP flag is normally superfluous in today's
>terminal hardware and software", why is it a required feature? ...

Read the rest of the paragraph containing that phrase.  "...it is
historically supported.  Therefore, applications may be using ISTRIP,
and there is no technical problem with supporting this flag.  Also,
applications may wish to receive only 7-bit input bytes and may not
be connected directly to the hardware terminal device (for example,
when a connection traverses a network)...  Also, there is no requirement
in general that the terminal device ensures that high-order bits beyond
the specified character size are cleared.  ISTRIP provides this function
for 7-bit characters..."

In other words, it does have potential uses for applications that really
do want to see only 7-bit input.  Those applications arguably are broken
and need fixing, but supporting them -- while the customers are still
buying and using them -- is trivial.  Standards are not in the business of
legislating morality; their job is to recognize reality.  If the customers
rise up and insist that those applications be fixed -- a development that
most of us would cheer -- then ISTRIP will fall out of use and eventually
can be removed from the standard.  While it remains in use, it is plausible
to include it in the standard, given that it is easy to support (which it
is, since it's about two lines of code in the terminal driver).
--
SVR4:  the first system so open that    | Henry Spencer @ U of Toronto Zoology
everyone dumps their garbage there.     |  [e-mail]  utzoo!henry


Volume-Number: Volume 26, Number 23

From [e-mail]  Wed Nov 27 16:44:52 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24397; Wed, 27 Nov 91 16:44:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28374; Wed, 27 Nov 91 16:44:40 -0500
Newsgroups: comp.std.unix
From: John F Carr <[e-mail]>
Subject: Re: Inventing standards
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Massachusetts Institute of Technology
References: <[e-mail]>
Date: Wed, 27 Nov 1991 20:59:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]>
    [e-mail] writes:

>Palladium is NOT widely implemented outside MIT.

It's not widely implemented inside MIT either.  Palladium Version 1
(c. 1989) was too broken to use.  The print software currently used by
Athena is Berkeley lpr with optional Kerberos authentication and print
quotas added.  As far as I know, MIT's plans for the new version of
Palladium are limited to delivering a product to the OSF.

(The extent of my involvement with Palladium is that I tried to use it
during testing 2 years ago.  I found it a very effective tool for
paper conservation, but that's more of a comment on implementation
than design.)

--
    John Carr ([e-mail])


Volume-Number: Volume 26, Number 24

From [e-mail]  Thu Nov 28 00:43:56 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20089; Thu, 28 Nov 91 00:43:56 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27487; Thu, 28 Nov 91 00:43:53 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: POSIX Printing
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 27 Nov 1991 13:08:54 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

% Submitted-by: [e-mail] (Duke Robillard)
%
%                    Excerpts from
% POSIX 1003.7a Printing Small Group Minutes, October 21-24, 1991

%   The meeting started with a review of last quarter's work.  At the
% last meeting, the functionality of Palladium and lp CLI's was merged
% into a new set of commands, all starting with the prefix "xp."  This
% work was brought into question.  There were concerns that POSIX
% shouldn't invent new interfaces.  The widespread acceptance of OSF's
% DME product, including USL's recent announcement regarding the ACE
% iniative seemed to mitigate the concern about Palladium's limited
% distribution, since it is part of DME.  This facts, along with the
% lack of an advocate for lp, led to the abandonment of the xp commands
% and a return of Palladium's pd commands.

  This is distressing.  I just this morning got an email note from one
of the users of Athena at MIT who said that Palladium had so many
problems that it isn't even in wide use at MIT and that BSD's lpr
protocol is in wider use.  I've urged him to post his comments
directly to this list since I don't feel comfortable quoting email to
news without permission.  That some other organisation chooses
a technology without sufficient actual experience should not cause
POSIX to make the same mistake.

%   If 1003.7a is going to meet its ballot date goals, the quesion of
% whether to use lp, pd, a new command set, or some mixture of these
% must be decided for the final time at the next meeting.  The printing
% small group urges anyone with an interest in this to come to Irvine,
% California for the January 13-17 POSIX meeting, or to send written
% proposals or arguments.

Well it is largely out of 1003.7a's hands whether to standardise lp(1)
because it has already been done as part of 1003.2's efforts.  If
what is meant is the question of standardising the historical user
interface commands (lpadmin/lpstat/lpr/lpq), then the clear choice
that USERS want is to standardise existing practice.  The trade rag
UNIX TODAY had an article this week about the desires of users that
makes interesting reading.

%   The next debate was about which API to use.  There was some
% discussion about adopting Tivoli's "objcall" interface from the DME.
% No one was very familiar with it, but it seemed to be a lower level
% interface, designed for general object management rather than
% printing.  Since the SVR4's lp system doesn't have an API, this was
% really a debate about which level of Palladium API to use.

Pity.  There isn't sufficient experience with any API to standardise
one.  It should be left unstandardised for the present rather than
adopting technology that hasn't been widely used and for which there
is currently insufficient experience.

% The high-level interface ("API") was eliminated first, because of its
% limited value added over just calling the CLI.  The low-level
% interface ("pdlib + RPC/IDL") was also elimnated because of its close
% ties to a specific RPC mechanism.  The middle-level interface ("SPI")
% was selected.  It allows developers to write new CLIs and GUIs, but is
% still manipulating the ISO print objects.  This interface won't insure
% interoperability, but 1003.7 is counting on its managed object
% definitions to do that.

Great.  Even 1003.7 says that their invented technology "won't insure
interoperability" and the lack of experience means that no one can know
if it will even work correctly.

% Which command set: pd*, lp*, or some mix.  A debate & vote
% Monday during the 1003.7 plenary.

  Go with something from the set lpadmin/lpstat/lprm/lpq all of which
have lots of implementation experience, are widely implemented in
historical systems, are known to work, and are widely known to users
and administrators at present.

% Review and update CLI section of draft, particularly rationale
% & test assertions.  Decide on required vs optional commands

Do you mean "command line interface" ??  If so, see comments above.

  Please note that I'd find optional Palladium commands less
objectionable if the conventional commands (see above) were made
mandatory.

% Review and update SPI section of draft.  Work on SPI
% test assertions.

What is meant by SPI ??

% Address 1003.6 (POSIX Security) concerns.

  Please contact folks in 1003.6 in this regard.  The problems in the
trusted systems field are not widely understood outside practioners
and by coordinating early much grief can be avoided.  Also please
examine the current 1003.6 draft which is out for balloting.

% Address Internationalization concerns.

  This should at least include being certain that 7/8/16/32 bit wide
characters will work with whatever is devised since those widths
are all used in ISO standards (including 2DIS 10646).

% Additions to ISO Print Objects

  What is meant here ??


Randall Atkinson
[e-mail]

Volume-Number: Volume 26, Number 25

From [e-mail]  Fri Nov 29 16:03:24 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09710; Fri, 29 Nov 91 16:03:24 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11903; Fri, 29 Nov 91 16:01:31 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 29 Nov 1991 18:01:01 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
>In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>>If you need all 8 data bits for your terminal connection then simply don't
>>specify ISTRIP to the terminal handler.
>... it is my claim that ISTRIP is required to be supported and that if you
>support it as described by the standard, then 8 bit code sets will be
>destructively translated on input.

No, read what I said again.

>As an example, EBCDIC has its characters spread throughout the entire
>8 bit range.  If ISTRIP should become turned on, ...

How?  I assure you that ISTRIP (or its equivalent) is not getting
mysteriously turned on on any of the systems I use; my terminal uses
an 8-bit binary packet protocol and I have never seen it broken by a
sudden shift into ISTRIP mode.  If your system has such a bad bug,
you should get the bug fixed rather than rail against the availability
of an often-useful feature.

>There is no room to change ISTRIP to be more meaningful in the
>>environment which it exists in because the standard has explicitly
>>stated that it must exist, and that it must behave in a specific fashion.

Yeah, standards are funny that way.

>If, as the Rationale says "Although the ISTRIP flag is normally superfluous
>in today's terminal hardware and software", why is it a required feature?

Basically, it was one of numerous tty handler capabilities provided by
the standard implementation on which the 1003.1 specification was based;
there are several of these (ioctl bits) that aren't widely useful; if
they don't meet your needs then you should feel free to not use them.
Generally, the interface bit rate, framing, parity, etc. should not be
altered by applications; they should be left exactly as established by
the system agent that established the tty port connection.


Volume-Number: Volume 26, Number 26

From [e-mail]  Sun Dec  1 15:19:46 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06771; Sun, 1 Dec 91 15:19:46 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09167; Sun, 1 Dec 91 15:19:44 -0500
Newsgroups: comp.std.unix
From: "M. J. Shannon Jr." <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Summary: Obsolescent features
Originator: [e-mail]
Keywords: CS5 CS6
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: MJS's Box, Plainfield, NJ, USA
References: <[e-mail]> <[e-mail]>
Date: Sun, 1 Dec 1991 08:48:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (M. J. Shannon Jr.)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>Basically, it was one of numerous tty handler capabilities provided by
>the standard implementation on which the 1003.1 specification was based;
>there are several of these (ioctl bits) that aren't widely useful; if
>they don't meet your needs then you should feel free to not use them.

Yes, I find particularly amusing the CS5 and CS6 character sizes.  Is
there a currently manufactured *anything* that supports (or, Goddess
forbid, *requires*) 5-bit characters?  (Yes, I know the ancient Baudot
code is a 5-bit code.  Alas, I am old enough to have hacked such a
beast (but I was only 2 years old at the time :-)).

>Generally, the interface bit rate, framing, parity, etc. should not be
>altered by applications; they should be left exactly as established by
>the system agent that established the tty port connection.

And the interface parameters should probably have been separated from
the character interpretation parameters, but, again, standards are
funny that way....

--
--------------+ <Delapsus Resurgam: When I fall I shall rise. --(10cc)>
Marty Shannon | My opinions are just that.  You may share them.  No one
[e-mail]| speaks for me, and I speak only for myself -- no matter
--------------+ where I post from.  Get it?        Post no flames.

Volume-Number: Volume 26, Number 27

From [e-mail]  Sun Dec  1 15:19:48 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06778; Sun, 1 Dec 91 15:19:48 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09176; Sun, 1 Dec 91 15:19:47 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]>
Date: Sun, 1 Dec 1991 18:41:54 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Bob Lenk writes:
> In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> >    cc -Dmacrostufff -Iheaderdir -c -O foo.c bar.o mylib.a -lX
> > The requirement that this invocation (when -I etc. aren't being used)
> > obtain a C implementation that conforms to the C standard could be left
> > as a separate specification, not necessarily required for 1003.2 proper.
> Then what use would the 1003.2 spec be?

It would document what UNIX systems do. Why are you trying to mandate
particular standards of quality? Just because you think high-quality cc
implementations should compile ANSI C is no reason to require everyone
to come up to that level of quality.

> An application (script/makefile)
> using it couldn't depend on it compiling standard C, or K&R C, or 6th
> edition C, or perhaps even Cobol.

Don't you trust the market to do *anything*? If a vendor markets a UNIX
system where cc compiles Cobol, it won't last too long. (Well, unless
it's IBM.) It's not a disaster that cc doesn't always support ANSI C:
that's *how the world works*! People still manage to write portable
code.

POSIX seems to have decided that portable applications *need* cc (or
c89, whatever) to compile ANSI C. Why? On what basis was it decided that
this area needed standardization? The market certainly hasn't made the
same decision. Have you ever considered erring on the side of caution?

---Dan


Volume-Number: Volume 26, Number 28

From [e-mail]  Sun Dec  1 16:20:10 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07836; Sun, 1 Dec 91 16:20:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12469; Sun, 1 Dec 91 16:20:08 -0500
Newsgroups: comp.std.unix
From: Sean Eric Fagan <[e-mail]>
Subject: Re: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Kithrup Enterprises, Ltd.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 1 Dec 1991 20:26:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>POSIX seems to have decided that portable applications *need* cc (or
>c89, whatever) to compile ANSI C. Why?

I can think of situations in which an application would need to be able to
rely on the behaviour of 'cc.'  What kind of code it accepts, what options
it takes, things like that.

The first situation is an application that generates a program, for some
reason, and needs to compile it.  Perhaps you've taken a look at emacs,
perl, or rn sources?  By guaranteeing *what* the compiler will accept (e.g.,
ANSI-C), the needs for ifdef's (supposedly) goes away.

Another situation is for something like Larry Wall's Configure, or a package
distributed with sources and a Makefile.  The goal of POSIX is that this
makefile will be portable among all compliant systems, as well as the code.

Lastly, please note that .2 did *not* 'standardise' "cc"; they standardized
"c89," a compromise *I* think is ok.

--
Sean Eric Fagan
[e-mail]

Volume-Number: Volume 26, Number 29

From [e-mail]  Sun Dec  1 18:45:03 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10981; Sun, 1 Dec 91 18:45:03 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25970; Sun, 1 Dec 91 18:45:01 -0500
Newsgroups: comp.std.unix
From: "W. Richard Stevens" <[e-mail]>
Subject: tty hardware flow control
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX.1
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Sun, 1 Dec 1991 21:52:42 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (W. Richard Stevens)

Anyone know why POSIX.1 ignored hardware flow control?
Looking at 5 different Unix flavors, 4 of which support
the POSIX.1 <termios> interfaces, all 5 have a different
way of enabling/disabling hardware flow control on a
tty port.  Sure would have been nice to have this
standardized.

    Rich Stevens  ([e-mail])

Volume-Number: Volume 26, Number 30

From [e-mail]  Mon Dec  2 16:44:48 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27140; Mon, 2 Dec 91 16:44:48 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26412; Mon, 2 Dec 91 16:44:44 -0500
Newsgroups: comp.std.unix
From: John F Haugh II <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: John F Haugh II <[e-mail]>
X-Submissions: [e-mail]
Organization: Somewhere in Simpson Bay, Sint Maarten, Nederland Antilles
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 2 Dec 1991 14:33:47 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>No, read what I said again.

I did read it again - and the question remains, what if I do (for some
God awful reason) specify ISTRIP to my terminal handler?  In an
environment where that can't POSSIBLY be a useful action, how should
the system react?

>How?  I assure you that ISTRIP (or its equivalent) is not getting
>mysteriously turned on on any of the systems I use; my terminal uses
>an 8-bit binary packet protocol and I have never seen it broken by a
>sudden shift into ISTRIP mode.  If your system has such a bad bug,
>you should get the bug fixed rather than rail against the availability
>of an often-useful feature.

This has nothing to do with SYSTEM supplied software.  I can control
the system software to never ever turn that feature on - that's the
easy part.  The hard part is doing the same for the end user.  My
claim (read this real carefully) is that the USER is being given a
means of shooting themselves in the foot which serves no useful
purpose.  For a system which requires 8-bit data, ISTRIP is never
an "often-useful feature".  It is a completely meaningless and
destructive data transformation.  It isn't benign like XTABS, or
XCASE or even the Model 37 carriage delays (which are completely
harmless to all but the impatient).  Transforming 0x81 to 0x01 is
WRONG and can't be made "right" somehow.  If you wish to reply,
please address that point.

>Basically, it was one of numerous tty handler capabilities provided by
>the standard implementation on which the 1003.1 specification was based;
>there are several of these (ioctl bits) that aren't widely useful; if
>they don't meet your needs then you should feel free to not use them.
>Generally, the interface bit rate, framing, parity, etc. should not be
>altered by applications; they should be left exactly as established by
>the system agent that established the tty port connection.

And what do you do when they DO somehow get changed?  The standard
says I am free to ignore speed, character size and parity changes
if the hardware doesn't support them.  ISTRIP, which is really a
function best described in terms of character size and parity bits,
doesn't fall under this same privision.  It is completely obvious
to me that the SYSTEM shouldn't contain any of these mistakes, but
I want to know what leaway POSIX left to insure the USER doesn't
commit the same blunder.  Setting an 8-bit interface to 5 bits has
as escape route - ignore the change.  Same for parity changes and
baud rate.  The $64M question is, why not ISTRIP?

You are reading this as though I am the programmer, not the implementor
and as though the programmer (my customer) is going to smile after
pointing a gun at his foot, pulling the trigger, and discovering the
hole that I warned him about.  My intention is that you view this as
a "Quality of Implementation" sort of issue - consider if the "privilege"
required by link() for directories is "the Earth is still spinning on
its axis".  How much sympathy would a user who creates a directory mess
have for you, the implementor, after being bitten by this "feature"?
Would you buy a POSIX-compliant system which behaved this way?
--
John F. Haugh II        | Every 56 days.   | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] | Give Blood, often.    | Domain: [e-mail]
" ... expectation is the mother of disappointment."
        -- Brad Konopik

Volume-Number: Volume 26, Number 31

From [e-mail]  Mon Dec  2 16:44:52 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27225; Mon, 2 Dec 91 16:44:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26446; Mon, 2 Dec 91 16:44:50 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: tty hardware flow control
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Mon, 2 Dec 1991 17:45:26 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (W. Richard Stevens)
>Anyone know why POSIX.1 ignored hardware flow control?

One possible reason is that until very recently -- bearing in mind that
POSIX.1 settled into its fairly-final form some years back -- any such
usage of the modem-control lines for flow control was itself a violation
of the relevant standards (RS232C and friends).  No, Virginia, CTS and
RTS were not assigned to flow control, much less DSR and DTR; they are
for talking to modems in internationally-standard ways that have nothing
at all to do with flow control, despite their relevant-sounding names.

I believe that RS232D actually has sanctioned use of CTS and RTS for flow
control, but there's still a distinct lack of standardization in how
hardware flow control works in real life.  I'm inclined to agree that a
standard way to turn it on and off would be a good thing, even in the
absence of a precise spec for how it works, but I can see why it was too
fuzzy an area for POSIX.1 to get into.
--
SVR4:  the first system so open that    | Henry Spencer @ U of Toronto Zoology
everyone dumps their garbage there.     |  [e-mail]  utzoo!henry


Volume-Number: Volume 26, Number 32

From [e-mail]  Mon Dec  2 21:14:07 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02762; Mon, 2 Dec 91 21:14:07 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03187; Mon, 2 Dec 91 21:14:04 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Dec 1991 00:25:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (John F Haugh II)
>... the question remains, what if I do (for some
>God awful reason) specify ISTRIP to my terminal handler?  In an
>environment where that can't POSSIBLY be a useful action, how should
>the system react?

The same way it reacts to other useless actions:  sigh and comply.

>My claim (read this real carefully) is that the USER is being given a
>means of shooting themselves in the foot which serves no useful
>purpose...

Doug and I (I think I can speak for Doug on this) don't understand why
you are getting so upset about one obscure method of foot-shooting in
a system that provides such an abundance of them.

>... It is a completely meaningless and
>destructive data transformation.  It isn't benign like XTABS, or
>XCASE ...

I can assure you that XTABS and XCASE are *not* benign in the general case.
I'm afraid you are arguing based on the very specific characteristics of
what you imagine your customers will want.

>... The standard
>says I am free to ignore speed, character size and parity changes
>if the hardware doesn't support them...

Note, however, that it doesn't say you are free to ignore them just
because *you* think the customer is never going to want them -- only
if it is literally impossible to provide them can you do so.  Note
that one purpose offered by the Rationale for ISTRIP is an 8-bit system
feeding an application that only wants to see 7 bits.  Why are you so
certain that not one of your customers will ever want this?

A standard is a treaty between the customer and the implementor.  To be
POSIX.1 compliant, you have to provide ISTRIP, even if you think it is
useless, because POSIX.1 promises the customer that it will be there
if he wants to use it.  Even if he wants to use it to shoot himself in
the foot.  POSIX.1 is a set of tools, some of them with sharp edges, not
a playpen for the novice.
--
SVR4:  the first system so open that    | Henry Spencer @ U of Toronto Zoology
everyone dumps their garbage there.     |  [e-mail]  utzoo!henry


Volume-Number: Volume 26, Number 33

From [e-mail]  Tue Dec  3 13:27:06 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23193; Tue, 3 Dec 91 13:27:06 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29768; Tue, 3 Dec 91 13:27:03 -0500
Newsgroups: comp.std.unix
From: John F Haugh II <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: John F Haugh II <[e-mail]>
X-Submissions: [e-mail]
Organization: Somewhere in Simpson Bay, Sint Maarten, Nederland Antilles
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Dec 1991 14:49:32 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>A standard is a treaty between the customer and the implementor.  To be
>POSIX.1 compliant, you have to provide ISTRIP, even if you think it is
>useless, because POSIX.1 promises the customer that it will be there
>if he wants to use it.  Even if he wants to use it to shoot himself in
>the foot.  POSIX.1 is a set of tools, some of them with sharp edges, not
>a playpen for the novice.

I agree that the buyer should beware, and indeed the historical difference
between UNIX-like operating systems and vendor proprietary offerings is
the ease with which different functions are used - often to the possible
detriment of the user.  But I firmly believe that POSIX is going to have
to smooth out some of those rough edges if it is going to continue to
penetrate the markets that are increasingly occupied by "novices" who
don't speak English.
--
John F. Haugh II        | Every 56 days.   | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] | Give Blood, often.    | Domain: [e-mail]
" ... expectation is the mother of disappointment."
        -- Brad Konopik


Volume-Number: Volume 26, Number 35

From [e-mail]  Tue Dec  3 13:47:12 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23996; Tue, 3 Dec 91 13:47:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04960; Tue, 3 Dec 91 13:47:10 -0500
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Dec 1991 14:26:17 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
> I did read it again - and the question remains, what if I do (for some
> God awful reason) specify ISTRIP to my terminal handler?  In an
> environment where that can't POSSIBLY be a useful action, how should
> the system react?

By screwing you over... just as it would if you type "stty 19200" when you're
connected via a 2400 baud modem.

> My claim (read this real carefully) is that the USER is being given a
> means of shooting themselves in the foot which serves no useful
> purpose.

Oh no? No user is ever going to connect an obsolete terminal to a serial port
on any installations of your fancy new computer anywhere in the world? You're
never going to use a public data service to dial it up? Lucky you.

> For a system which requires 8-bit data, ISTRIP is never
> an "often-useful feature".

When you're dialed up through a 7-bit data path with some unknown and
unpredicted parity setting it's nice to still be able to login.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 26, Number 36

From [e-mail]  Tue Dec  3 14:13:54 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26673; Tue, 3 Dec 91 14:13:54 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11288; Tue, 3 Dec 91 14:13:51 -0500
Newsgroups: comp.std.unix
From: Donald Lewine <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Data General Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Dec 1991 17:03:22 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Look, one of us is being quite dense here and I don't think it is me.
I am open to the possibility that I am grossly misunderstanding you,
but I doubt it. . .

In article <[e-mail]>, [e-mail] (John F Haugh II) writes:
|> I did read it again - and the question remains, what if I do (for some
|> God awful reason) specify ISTRIP to my terminal handler?  In an
|> environment where that can't POSSIBLY be a useful action, how should
|> the system react?
The same way the system reacts to any stupid action.  What if (for some
God awful reason), I specify exit() where I mean printf()? Or I type
"rm" when I mean "ls"?  The result is bad, I admit it.  It is less bad
than my stomping on the gas in my car instead of the break.  They are
all errors.  The world provides for countless damage due to user
errors.  In the grand scheme of things, ISTRIP is far less dangerous
than, say, "I did not know the gun was loaded."

|>
|> >How?  I assure you that ISTRIP (or its equivalent) is not getting
|> >mysteriously turned on on any of the systems I use; my terminal uses
|> >an 8-bit binary packet protocol and I have never seen it broken by a
|> >sudden shift into ISTRIP mode.  If your system has such a bad bug,
|> >you should get the bug fixed rather than rail against the availability
|> >of an often-useful feature.
|>
|> This has nothing to do with SYSTEM supplied software.  I can control
|> the system software to never ever turn that feature on - that's the
|> easy part.  The hard part is doing the same for the end user.  My
|> claim (read this real carefully) is that the USER is being given a
|> means of shooting themselves in the foot which serves no useful
|> purpose.  For a system which requires 8-bit data, ISTRIP is never
|> an "often-useful feature".  It is a completely meaningless and
|> destructive data transformation.
As I think about, ISTRIP is one of the more benign ways to screw
up a call to tcsetattr().  There are many ways which will leave you
terminal hung in a state where there is nothing you can do (at least from
that terminal) to fix it.

|> It isn't benign like XTABS, or
|> XCASE or even the Model 37 carriage delays (which are completely
|> harmless to all but the impatient).  Transforming 0x81 to 0x01 is
|> WRONG and can't be made "right" somehow.  If you wish to reply,
|> please address that point.
I don't claim there is any way to make it "right."  I claim that
setting the ISTRIP bit is only one of thousands of errors a user can
make.  I also claim that it is a relatively minor error that is
fairly easy to debug.

It is no worse than the programer writing:
    ch &= 0x7f;
when he ment:
    ch &= 0xff;

It is a lot less of a problem than typing "rm" instead of "ls".  I
know of people who have done that.  I know of no one who ever turned
on ISTRIP by accident.

NOTE: Calling tcsetattr() with a bad pointer can cause much more
      grief than merely setting ISTRIP.

In short, a program can set ISTRIP by mistake and cause incorrect
operation.  This error is not on the top 100 programming errors list
and is not worth the net bandwidth we have already given it!

--------------------------------------------------------------------
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 26, Number 37

From [e-mail]  Wed Dec  4 20:15:57 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28982; Wed, 4 Dec 91 20:15:57 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10654; Wed, 4 Dec 91 20:15:55 -0500
Newsgroups: comp.std.unix
From: Donn Terry <[e-mail]>
Subject: Re: tty hardware flow control
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Wed, 4 Dec 1991 15:06:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

POSIX.1 ignored HW flow control for several reasons:

    1) No-one asked (loud enough to be heard, anyway).

    2) There is no de-facto standard, and the pressure wasn't
       there to invent.

    3) It's unclear (at least to me) what the API to that might be.
       (Wouldn't it all be in the wiring of the connector cable?)
       Maybe not, but if it is then it's out of scope because
       that's a HW (in this case EIA) standard.  The most POSIX
       could talk about is the API.

Proposals always welcome (but be sure it's in scope).

Donn Terry
Speaking only for myself.


Volume-Number: Volume 26, Number 39

From [e-mail]  Wed Dec  4 20:16:01 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28991; Wed, 4 Dec 91 20:16:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10677; Wed, 4 Dec 91 20:15:59 -0500
Newsgroups: comp.std.unix
From: Andrew Hume <[e-mail]>
Subject: Re: Does AT&T System VR4 comply with POSIX 1003.2 ??
Message-Id: <[e-mail]>
Summary: what if there is no cc?
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
References: <[e-mail]> <[e-mail]>
Date: Wed, 4 Dec 1991 06:37:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

    Not that it is a widely used system (yet), but plan 9 doesn't
even have a cc command. But there is a directory with a c89 in it.
I would quibble with at least several of teh compromises in 1003.2,
but c89 is not one of them.

        andrew


Volume-Number: Volume 26, Number 38

From [e-mail]  Wed Dec  4 20:16:02 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28996; Wed, 4 Dec 91 20:16:02 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10679; Wed, 4 Dec 91 20:15:59 -0500
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: POSIX v. non-ASCII character sets
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 4 Dec 1991 17:42:43 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
> I firmly believe that POSIX is going to have
> to smooth out some of those rough edges if it is going to continue to
> penetrate the markets that are increasingly occupied by "novices" who
> don't speak English.

I definitely agree that *someone* needs to, but I'm not sure that it's
POSIX's job. At least, it's not the job of any P1003 committee as currently
chartered. Perhaps it would be useful to aim for a "UNIX Lite" and get some
people to create a P1003 standard for it. Certainly it'd be more useful
than some of the existing groups.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"



Volume-Number: Volume 26, Number 40

From [e-mail]  Wed Dec 11 04:16:05 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01262; Wed, 11 Dec 91 04:16:05 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28546; Wed, 11 Dec 91 04:16:02 -0500
Newsgroups: comp.std.unix
From: Tom Limoncelli <[e-mail]>
Subject: POSIX standards for GUIs?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Mentor Graphics, Silicon Design Division
Date: Thu, 5 Dec 1991 22:32:28 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Is there a working group to come up with a standard for programming
interfaces to GUIs?  That is, a set of calls (implemented as a library
or whatever) that will "do the right thing" no matter what GUI (Motif,
OpenWin, etc.) you are running?

Please email me and I will post a summary.

Thanks,
Tom Limoncelli
[e-mail]
--
Tom Limoncelli -- [e-mail] (work) -- [e-mail] (play)

[ I don't have anything from the GUI groups in the archives on uunet;
  if someone wants to start sending me status reports, snitch reports,
  whatever, I'll be glad to post and archive them -- mod ]

Volume-Number: Volume 26, Number 41

From [e-mail]  Thu Dec 12 17:34:37 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13918; Thu, 12 Dec 91 17:34:37 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25092; Thu, 12 Dec 91 17:34:34 -0500
Newsgroups: comp.std.unix
From: "Dave Brower, DBMS hack, [510] 748-3418" <[e-mail]>
Subject: Forlorn by 1003.4
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Ingres, an ASK Company
Date: Thu, 12 Dec 1991 06:54:41 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Brower, DBMS hack, [510] 748-3418)

Dear Miss Standards,

I've been balloting the 1003.4 RT stuff, and been participating off
and on in UI working groups.  The UI TPWG actually accepted my request,
but then it got lost in the shuffle.  1003.4 has been even less amendable
to our needs.

Let me try to explain here to see if I'm nuts, and what you think I
should do.

We write a server program that gets requests from many other
processes, and sends back responses.  It would be great to have a very
high-performance way of sending messages back and forth between the
two, and we've wanted to use a system provided "Message" facility to
do this for a long time.

The missing piece for us is determining the identity of the client
process, so we know what of our own permissions/privileges etc. to
invoke during processing of the request.

The way we'd like to get it is to have the system put the effective
uid of the message sender in the header that comes when we receive the
message.  We think that this would take a whopping uid_t worth of
space in the header, and maybe 10 extra instructions in the system to
fill in field and copy it out to user space.  This would provide us
with trustworthy accreditation, and we can proceed easily from there.

People misunderstanding the problem have suggested a number of things
that don't work:

(1) Have the sender put it's id in the message.  This doesn't work
    because we can't trust the sender to tell us the truth.

(2) Rely on access permissions on the message queue.   That only affects
    whether we accept the message or not; it doesn't give us any ability
    to treat requests from different users differently.

(3) Set up a message queue for each client.  This doesn't scale well,
    and defeats the entire purpose of multiplexing requests into a
    single queue.

I turned in a "NO" vote to 1003.4 because it didn't do what we needed.
I was asked to withdraw my objection in the last recirculation
because "the message model is all different now" and because "we
punted it to the network API group."

The current position is rationalized more or less as

    (a) we're only doing what is "fast";
    (b) we're only doing what is has prior art;
    (c) we're only doing what is needed for "real time"
    (d) we're punting this to the network API folks...
    (e) it's too hard to do over a network.

Let me try to puncture these balloons one by one.

(a) It shouldn't cost hardly anything to put the euid of the sender
    into the header.  I'd appreciate hearing how it would be expensive.

(b) VMS mailboxes do provide authenticated sender id, so there is
    well-established prior art.

(c) The Posix Real-time work was clearly intended to carry on the
    work of the /usr/group database/ transaction processing group.  A
    fast local IPC mechanism usable for database was something that
    has been on the request list since at latest 1984.  Claiming this
    isn't within the charter/scope is hard to swallow.

(d) The networking APIs can only provide interfaces to facilities
    provided by the lower level transport mechanisms.  If the lower
    level doesn't support reliable sender ID, then the API isn't going
    to be able to conjure it up very easily.  So, if the IPC
    mechanism (messages) doesn't provide sender id, then you'll never
    get it.

(e) First, message queues aren't network objects so this is a false
    issue; Second, it's the same problem that a remote file service
    has in determining the owner of newly created file; that is, uid
    mapping is going to have to be solved anyway.

So, Miss Standards, is what I want really unreasonable?  Is my
explanation incomprehensible?  What do you think I should do?

thanks,

- a frustrated SQL server writer

--
"If it were easy to understand, we wouldn't call it 'code'"
David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb [e-mail]


Volume-Number: Volume 26, Number 42

From [e-mail]  Thu Dec 12 17:34:42 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13925; Thu, 12 Dec 91 17:34:42 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25106; Thu, 12 Dec 91 17:34:39 -0500
Newsgroups: comp.std.unix
From: Ed Kubaitis - CSO <[e-mail]>
Subject: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Thu, 12 Dec 1991 13:42:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ed Kubaitis - CSO)

The emulation of the select() system call on some System V platforms
does not work with pipes. That is, a select() on standard input from
a process created by popen(cmd, "w") will fail with error messages on
these platforms.

Will some POSIX standard address the behavior of select() on pipes?
Is there a draft standard?

Thanks.

----------------------------------
Ed Kubaitis ([e-mail])
Computing & Communications Services Office - University of Illinois, Urbana


Volume-Number: Volume 26, Number 43

From [e-mail]  Thu Dec 12 18:08:28 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15650; Thu, 12 Dec 91 18:08:28 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02532; Thu, 12 Dec 91 18:08:25 -0500
Newsgroups: comp.std.unix
From: Bill Norcott <[e-mail]>
Subject: XPG3 versus POSIX.2 versions of same utilities ??
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: XPG/3, POSIX 1003.2, utilitites
Nntp-Posting-Host: rodan.uu.net
Reply-To: Bill Norcott <[e-mail]>
X-Submissions: [e-mail]
Organization: Tandem Computers, Inc.
Date: Thu, 12 Dec 1991 19:20:54 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bill Norcott)

It is my understanding that "XPG4 base branding", which has not yet
been completely defined yet, will encompass POSIX 1003.1 and 1003.2.
That is, the XPG4 version of any utility which is also found in
POSIX.2, will conform  to the POSIX.2 definition of that utility.
This is apparently not the case with XPG3: there are XPG3 versions of
some utilities which do not conform to the (latest draft) POSIX.2
definition of the same utility.

I would like to get the list of all XPG3 utilities which must change
in order to be brought into conformance with POSIX 1003.2.  Can anyone
provide me with the list?

-- Bill Norcott                                    PHONE:  (408)
285-3253 Tandem Computers, Inc.          EMAIL: [e-mail]
10600 N. Tantau Avenue Cupertino, CA   95014

Volume-Number: Volume 26, Number 44

From [e-mail]  Fri Dec 13 00:05:43 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00517; Fri, 13 Dec 91 00:05:43 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02912; Fri, 13 Dec 91 00:05:41 -0500
Newsgroups: comp.std.unix
From: Scott Schwartz <[e-mail]>
Subject: Re: Forlorn by 1003.4
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: penn state university, computer science
References: <[e-mail]>
Date: Fri, 13 Dec 1991 02:12:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scott Schwartz)

[e-mail] (Dave Brower, DBMS hack, [510] 748-3418) writes:
| The way we'd like to get it is to have the system put the effective
| uid of the message sender in the header that comes when we receive the
| message.

|     (a) we're only doing what is "fast";

As described, it isn't slow.  It can also be optional.  In BSD, only
sendmsg would need to do the extra work, while send, sendto, write can
continue as always.  Surely POSIX can invent something comparable.

|     (b) we're only doing what is has prior art;

V10 sends uid.

|     (d) we're punting this to the network API folks...
|     (e) it's too hard to do over a network.

Realistically, there's a difference between sending messages between
machines and between processes on the same machine.  Why cripple local
ipc for the sake of similarity with network ipc?

Volume-Number: Volume 26, Number 45

From [e-mail]  Mon Dec 16 17:09:29 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10389; Mon, 16 Dec 91 17:09:29 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15163; Mon, 16 Dec 91 17:09:26 -0500
Newsgroups: comp.std.unix
From: Brian Button <[e-mail]>
Subject: POSIX.8 update??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Western Geophysical Exploration Products
Date: Mon, 16 Dec 1991 16:30:02 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Brian Button)

Does anyone out there know the status of POSIX.8, the Networking stuff?

--

Brian Button
email : [e-mail]

Volume-Number: Volume 26, Number 46

From [e-mail]  Mon Dec 16 17:09:31 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10396; Mon, 16 Dec 91 17:09:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15191; Mon, 16 Dec 91 17:09:29 -0500
Newsgroups: comp.std.unix
From: Jason Zions <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: Mon, 16 Dec 1991 20:02:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Will some POSIX standard address the behavior of select() on pipes?

The _ad_hoc_ System Interfaces Coordinating Committee, meeting at the
October POSIX meeting, discussed finally doing something about the
"select()" problem, i.e.  that no work was being done on it in any POSIX
standard. While no firm conclusions were reached, some progress was made on
figuing out which group (and which standard) would include the work on
standardizing the select() interface; more importantly, some progress was
made on figuring out how to cvoordinate that work so that the networking
gang(s) and the 1003.1 gang and the real-time gang could all *share* that
interface and jointly develop the standard text for it.

Since standards development is broken up along funcitonal lines in POSIX,
those interfaces which cut across those lines (e.g. open(), select())
present challenges. There is an expectation that one can open() a local
file, a remote file, a real-time message queue, a secure file, and a named
network connection, all with a function whose name is open() and has some
common parameters. Coordinating the writing of the various pieces of
standards so they all fit into some tightly-integrated yet useful definition
of open(), especially when all those pieces will be balloted and published
asynchronously, is hard. With open(), the 1003.1 gang got there first, so
everyone coordinated with and through them. With select(), *no one* got
there first, and no one was, until recently, willing to volunteer to serve
the role.

>Is there a draft standard?

Not yet. But there's the barest hint of a written plan (in the minutes of
the SICC meeting) as to how we're going to address select()...

DISCLAIMER: Although I am a member of the _ad_hoc_ SICC, I do not in any way
speak for it, or for any other part of POSIX, etc. and so forth. I'm
speaking from (all too fallible) human memory; any one of the other players
may contradict me with impunity. Such is life.

Jason Zions


Volume-Number: Volume 26, Number 47

From [e-mail]  Tue Dec 17 15:23:04 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24784; Tue, 17 Dec 91 15:23:04 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26145; Tue, 17 Dec 91 15:23:03 -0500
Newsgroups: comp.std.unix
From: Alan Beal <[e-mail]>
Subject: SQL Access and X/Open
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: The Design Committee
Date: Mon, 16 Dec 1991 22:54:52 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alan Beal)

I have read that X/Open is a member of the SQL Access group, but I was
wondering if X/Open publishes any other the SQL Access documents?  Is
there an address for the SQL Access Group and a list of available documents?
--
Alan Beal
Internet: [e-mail]
USENET:   {uunet,uunet!bywater!scifi}!paladin!beal


Volume-Number: Volume 26, Number 48

From [e-mail]  Tue Dec 17 15:23:07 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24805; Tue, 17 Dec 91 15:23:07 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26155; Tue, 17 Dec 91 15:23:05 -0500
Newsgroups: comp.std.unix
From: Jason Zions <[e-mail]>
Subject: POSIX.8 update??
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: Tue, 17 Dec 1991 17:53:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Does anyone out there know the status of POSIX.8, the Networking stuff?

Nearly two years ago, what was known as POSIX Networking, 1003.8, split into
several different working groups. (Historians will record this as the day
networking MIRV'ed.) The split was as follows:

1003.8    Transparent File Access. Current at Draft 5; about to enter ballot.
    Ballot group has closed.

1003.12 Protocol Independent Interface. Subdivided work into  Simple Network
    Interface (SNI) and Detailed Network Interface (DNI), with DNI at
    roughly the level of Sockets/XTI. Still a year or so away from
    ballot on DNI; SNI to follow.

1003.17 Directory Services API. Draft 2 (perhaps 3 by now). Moving rapidly.

1224    X.400 interface. At draft 3 (4?). Ballot group has closed; balloting
    should begin soon.

1237    Remote Procedure Call interface. PAR withdrawn; working group has
    essentially merged, in the US, with the X3T5.5 RPC group.

1238    Common OSI API and FTAM API. Progressing on core OSI services more
    quickly than on FTAM; working with 1003.17 to ensure a common
    underpinning.

Contact information for each of these groups is available from the IEEE, as
is information on getting mailings.

All the work of the various TCOS-SS networking groups is coordinated by the
TCOS-SS Distributed Services Steering Committee, a standards steering
committee set up by the TCOS-SS SEC for that purpose. The chair of the DSSC
is Tim Baker, of Loral Space Information Systems in Houston, Tx; e-mail is
[e-mail].

For those who are truly interested in following the progress of IEEE-CS
standards, I must strongly recommend subscribing to the IEEE-CS Standards
Status Report, a quarterly which names all currently authorized projects,
officers (with addresses etc.), document status, and other reports. Very
valuable.

Jason Zions
Chair, 1003.8 Transparent File Access
#include <usual.disclaimer>


Volume-Number: Volume 26, Number 49

From [e-mail]  Fri Dec 20 02:14:02 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10876; Fri, 20 Dec 91 02:14:02 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB12730; Fri, 20 Dec 91 02:13:58 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]>
Date: Wed, 18 Dec 1991 21:59:56 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Jason Zions writes:
> There is an expectation that one can open() a local
> file, a remote file, a real-time message queue, a secure file, and a named
> network connection, all with a function whose name is open() and has some
> common parameters.

*Why*?

Many people share this ``expectation.'' I don't understand why. Is it
because of ``the UNIX philosophy''? Or because a super-open() is
supposed to be easier for programmers? Or for users?

Let me dispose of these myths, one by one. First of all, ``the UNIX
philosophy'' is not ``everything's a file.'' Nor is it ``everything
has a name in the filesystem.'' It never was. In v7, pipes were not
files. Pipes still aren't files. Streams and sockets aren't in the
filesystem either.

The UNIX philosophy is that everything is a *file descriptor*. This is
why pipes are so useful---programs are written to use the *file
descriptors* 0, 1, and 2. File descriptors---and, most importantly, the
way that descriptors are inherited across fork() and exec()---are the
whole reason that tools work together better in UNIX than in any other
operating system. Input and output---read() and write()---work on file
descriptors uniformly. That's why tools work the same way whether
they're talking to a tty, a file, a pipe, a socket, or what have you.
*That's* the UNIX philosophy.

The UNIX philosophy doesn't give a damn how many syscalls there are to
create descriptors in the first place---as long as they all work with
read(), write(), dup(), close(), fork(), exec(), and so on. If it's so
important for UNIX that there be a single syscall to create new file
descriptors, how come v7 had *three* syscalls---not just open(), but
also pipe() and creat()? If you want to get rid of socket(), accept(),
socketpair(), connect(), and any other non-open() way of creating a
descriptor, all in the name of ``the UNIX philosophy,'' then why don't
you include pipe() in your super-open() too?

Let's move on to the supposed simplicity of super-open() for programmers.
Since when was it difficult to create, e.g., network connections with the
BSD syscalls? You can take any program you want---any program which uses
*file descriptors*, that is---and offer it as a service under inetd. Or
use any number of available packages (example: my clientserver package)
which let you do the same thing from shell scripts or inside programs.
Once you have a single utility which opens a network connection and passes
the *file descriptor* to the program of your choice, you can forget about
the details of network code and simply stick to read() and write(). Why
would a super-complex super-open() be any easier than this?

Or to take your example of ``a secure file''---there's a utility running
around which implements access control lists on any UNIX system. It works
the same way as the network utilities: it does the appropriate checks,
creates the *file descriptor*, and passes it to any program you specify.
There you have it: ACLs without super-open() and without any kernel mods!
Is it really supposed to be simpler to have even more flags and arguments
to open()?

Competent UNIX programmers write tools which stick to stdin, stdout, and
stderr. Only a few specialized tools---cat, sh, inetd---have to worry
about open() or pipe() or socket(). By adding a super-open() you might
make it a tiny bit easier to write those specialized tools, but you're
also bloating the kernel for something which the vast majority of
programs will never use. Why do you think the market hasn't even
considered a similar syscall?

Finally, let's consider super-open()'s advantages for users. Certainly
it'd be nice for a user to be able to type something like, say,

   % cat #[e-mail]

(disclaimer: I haven't given any thought to a good notation for this)
and have cat read from a TCP socket connected to port 13 on athena. Does
this mean that open() should support such notation? No! By kludging that
into the kernel you're taking control away from the user. The UNIX way
is much better for all concerned: *Let the shell worry about it*. Let the
shell parse #[e-mail] and invoke the right programs to set up a
network connection. Give users the freedom to choose shells which offer
the notations they like. Should I point out that several existing shells,
ksh for example, already provide such constructs?

``There is an expectation that one can open() a local file, a remote
file, a real-time message queue, a secure file, and a named network
connection, all with a function whose name is open() and has some common
parameters.'' Once again I ask: Why?

---Dan

Volume-Number: Volume 26, Number 50

From [e-mail]  Fri Dec 20 02:46:53 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11205; Fri, 20 Dec 91 02:46:53 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15210; Fri, 20 Dec 91 02:46:51 -0500
Newsgroups: comp.std.unix
From: Sean Eric Fagan <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Kithrup Enterprises, Ltd.
References: <[e-mail]> <[e-mail]>
Date: Fri, 20 Dec 1991 07:24:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>Many people share this ``expectation.'' I don't understand why. Is it
>because of ``the UNIX philosophy''? Or because a super-open() is
>supposed to be easier for programmers? Or for users?

Possibly both.  Having everything as a simple byte sequence certainly makes
some things easier (although, to be honest, it makes other things more
difficult).

You bring up the concept of pipes, which didn't exist as files in the
original systems.  Well, a lot of things weren't in the original systems
originally, either, and lots of people seem to think that some of the
additions since V7 were a good idea.  (The problem is that most of these
people don't agree that *all* of the additions were a good idea, and they
all have different ideas about what *was* a good idea to add 8-).)

I am currently discouraged that I can't create a socket in my filesystem;
there are things where it would be nice to do so.  Oh, I can kludge around
it, by making a named pipe, and using rsh/rcmd.  But a named TCP/IP socket,
to a specified host, would be nice.  (E.g., cp
/tcp/ip/ftp/uunet.uu.net/ftp/ls-lR.Z .)

Unix also has the idea of unnamed files; normally, these are things like
sockets or pipes, but they can also be files that were created, and then
unlinked.  Can you come up with a good reason (excluding efficiency, which
I'll mention in a bit) *not* to support the creation a named pipe in the
filesystem, forking, and then unlinking it, but keeping it open?  Yes, this
would be somewhat less efficient:  doing a mknod(), which also involves
going through the filesystem, then doing an unlink(), which is twice as many
system calls as pipe().

The question is:  is this amount of generalization worth it?  I'm not sure.
I think that it would probably be good for a research system (and, then,
maybe moving it into commercial systems, if the advantages are enough), but
I can't heartily agree with it.  Or disagree with it.

I'm not saying I disagree with Dan.  I'm just not saying I agree with him.
(I feel like Charlie Brown:  "I'll be wishy one day, and washy the next!")

Tell me, Dan, how do you feel about the /dev/fd filesystem/pseeudo devices?
As you point out, having every process know that it should use
filedescriptor 0 for input, 1 for output, and 2 for error reporting has made
a lot of things very easy for Unix and Unix programmers.  (And 3 as the "tty
device" is something that I don't necessarily agree with, but Plan 9 papers
seem to report that it has worked out pretty well.)  By having the file
descriptors available in the filesystem name space, it makes some things a
lot easier.  E.g., "vi /dev/fd/0"  (Ok, that's stretching it.  How about
ksh's use of it:  "sed <$(foo1) <$(foo2) <$(foo3)"  Using named pipes, of
course, would do the same thing, except you'd have to clean them up
afterwards.)

--
Sean Eric Fagan
[e-mail]

[ I'm going to ask people to use their judgement on this thread.  It might
  belong in one of the comp.unix groups instead of here.  -- mod ]

Volume-Number: Volume 26, Number 51

From [e-mail]  Fri Dec 20 17:42:49 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19798; Fri, 20 Dec 91 17:42:49 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00464; Fri, 20 Dec 91 17:42:42 -0500
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Fri, 20 Dec 1991 17:41:29 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> Jason Zions writes:
> > There is an expectation that one can open() a local
> > file, a remote file, a real-time message queue, a secure file, and a named
> > network connection, all with a function whose name is open() and has some
> > common parameters.

> *Why*?

Because the more things you can access via the open() system call, the more
powerful an environemnt you have. For example, older programs become able to
access more data sources and sinks without modification or recompiling.

For a concrete example, in AmigaDOS this expectation is taken further: you
can relatively easily create new objects that look like files, and pass
textual information to them in the open call. In general, "DEV:path" passes
the string "path" unmodified to the device "dev". This allows such nice
capabilities as:

    CON:0/0/640/200/Debug Window/WAIT

Which opens a (NTSC) full-screen window, titled debug window, which you can
print text strings to and which will hang around after close until you click
on the close box. Another example:

    APIPE:ps -ef

Reading from this file will give you the result of the "ps -ef" command. you
don't have to have the program calling popen with some syntaxes and not others,
you don't have to remember that some programs allow this and others don't. in
UNIX I can open a pipe, in various programs, by doing:

    :r !ps -ef
    open "ps -ef" pr
    ~|ps -ef

> Let's move on to the supposed simplicity of super-open() for programmers.
> Since when was it difficult to create, e.g., network connections with the
> BSD syscalls?

Not very, but it's hard to create one from your ".mailrc" file.

> Competent UNIX programmers write tools which stick to stdin, stdout, and
> stderr. Only a few specialized tools---cat, sh, inetd

A few specialised tools? cc, mail, diff, just off the top of my head. Not
everything is, or can be, a filter.

> also bloating the kernel for something which the vast majority of
> programs will never use.

The challenge is on... let's look though my System III (because it's older
and therefore more "pure") Xenix manual:

accton, awk, bdiff, bfs, chgrp, chmod, chown, cmp, comm, cp, cron, cu, diff,
diff3, ed, finger, join, ln, look, lpq, lpr, mail, make, more (and less),
mv, nohup, pr, rm, sdiff, tee, touch, and uucp (etc).

All these commands operate on, require, or provide access to named files in
ways that bare file descriptors can not easily be wedged in. This list also
brings up the question of security: all UNIX security is based on access to
files. Adding new ways to create file descriptors involves duplicating all
this security and causing a separate source of kernel expansion.

> Finally, let's consider super-open()'s advantages for users. Certainly
> it'd be nice for a user to be able to type something like, say,

>    % cat #[e-mail]

More like "cat /dev/telnet/athena.mit.edu/13".

> (disclaimer: I haven't given any thought to a good notation for this)
> and have cat read from a TCP socket connected to port 13 on athena. Does
> this mean that open() should support such notation? No!

I agree, in a way. It's not "open" that's doing the work... it's the virtual
file system mounted on /dev/telnet. If you rely in the shell to figure this
out and convert the call to something like

    + telnet athena.mit.edu 47| cat /dev/fd/47

then what do you do when you want to access this from "awk", or create a
(sumbolic) link to it called "/dev/weather"? And have this converted to a
link to a serial port with a heathkit WWV receiver when the network's down...

UNIX is more than just the shell.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 26, Number 52

From [e-mail]  Tue Dec 31 17:46:45 1991
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12965; Tue, 31 Dec 91 17:46:45 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07001; Tue, 31 Dec 91 17:46:39 -0500
Newsgroups: comp.std.unix
From: "Stephen R. Walli" <[e-mail]>
Subject: October IEEE POSIX Meeting Report
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 31 Dec 1991 15:54:09 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Stephen R. Walli")








       Report on the October 1991 IEEE POSIX Meeting for EurOpen
               Stephen R. Walli <[e-mail]>
              EurOpen Institutional Representative


      The October  meeting  of the  IEEE  POSIX committees  was  a
      strange mixture of  administrivia and crankiness. Perhaps it
      was merely my  outlook on the  latter. There was  no central
      theme for the week, as there has been in the past with items
      such as the GUI Wars.
      The foundation of  POSIX was under  attack this week in some
      interesting and possibly  necessary ways. These  discussions
      concern options and testability, and options (different) and
      profiling.  The Project Management Committee (PMC) made some
      carefully worded statements  about the continued sponsorship
      of P1201  (Graphic User  Interfaces), the Sponsor  Executive
      Committee (i.e. TCOS-SS Governing Board) meeting was over in
      record time Thursday  night, and we all went home, exhausted
      as usual.
      Other items  of  note include  a  debate over  the  upcoming
      European IEEE  POSIX  meeting next Fall,  and some new  work
      items for consideration.
      Let's start with the really interesting bits ....

      1.  Profiles and POSIX.1
      There was  considerable  discussion in  the POSIX.1  working
      group  (Base  Interfaces)   surrounding  the  old  issue  of
      chopping the standard up into chunks of functionality.  This
      discussion centres  around  the issue  of  whether or not  a
      profile can point to pieces of the POSIX.1 standard.
      The  POSIX.4   (Real-time   extensions)  document  has   its
      functionality divided up into separate sections, each called
      out by  an  option name. For  example, if an  implementation
      supports    binary     semaphores     then    the     symbol
      _POSIX_BINARY_SEMAPHORES is defined. This makes it very easy
      for a profile  to point to a piece of required functionality
      in the real-time document.
      POSIX.1 only  supports  a few  such  options for  conforming
      implementations:    NGROUPS_MAX,   _POSIX_JOB_CONTROL,   and
      _POSIX_CHOWN_RESTRICTED.
      The POSIX.13  real-time  profiling group  wants the  POSIX.1
      standard further optionized to allow its functionality to be
      called  out  separately,  such as  an  option for  the  file
      system, an option for process control, and so on. This would
      allow the  real-time embedded profile  to specify a  POSIX.1
      style file  system,  but not  require POSIX.1 style  process
      control.   The  embedded  profile  cares about  threads,  or
      possibly a  single  process.  Nothing  so ``cumbersome''  as
      multiple processes is required.
      There are  members of POSIX.1  who completely disagree  with
      this  view  of  the  standard.  POSIX.1 defines  a  portable
      programming interface which  serves a broad range of general
      applications. It is  viewed as a minimal set. Nothing may be
      removed. POSIX.1 can never be subsetted.
      Part  of  this has  to  do with  the  sanctity of  the  term



                     - 2 -



      ``POSIX''.  To  the  original standards  development  group,
      ``POSIX'' means POSIX.1.  If you come from the POSIX.2 Shell
      and Utilities group,  it means a POSIX.2 Shell and Utilities
      environment, which  doesn't  necessarily require  a  POSIX.1
      system underneath it.  Some people are magnanimous enough to
      recognize it to mean a POSIX.1 implementation with a POSIX.2
      Shell, and so on.
      There is a  real concern that anything else isn't POSIX, nor
      can it use  the name POSIX.  A terrible vision is painted of
      the existing DOS  environment, i.e. a loader and simple file
      system,  being  allowed  to  call  itself  POSIX  by  making
      functionality optional like process control.
      Coming  relatively  recent   to  the  IEEE  POSIX  standards
      development world, (I've only been mired in the muck for two
      years,) I quickly  learned to use the term ``POSIX'' to mean
      a family of  standards development projects. Indeed, this is
      the informal definition  discussed in the POSIX.1 standard's
      introduction.  If one  wants to discuss  POSIX.1 interfaces,
      one talks about  ``POSIX.1''. Likewise, if one is discussing
      POSIX.6 extensions,  one refers to  ``POSIX.6'', and so  on.
      This level of naming is required to remove ambiguity.
      There is also  no way to keep marketing departments clear on
      this.  They  will  continue to  misuse  and abuse  the  term
      ``POSIX''.  There is no protection for an ignorant consumer.
      The standard legislates  what needs to  be provided to claim
      POSIX.1 conformance.  It cannot police the market place.
      There is  a  genuine technical  issue  with dividing up  the
      POSIX.1 standard.  The division would  need to be  extremely
      clean and  concise.  Relevant definitions  from one  section
      would need to be carried with functionality discussed in the
      other  sections.  Any cross  referencing  would need  to  be
      handled  extremely   carefully.   Considering  the   current
      organization  and  wording   used  throughout  the   POSIX.1
      standard, it  would  not be  an  easy job  to  pick out  new
      options.
      This discussion will  likely carry on for some time as other
      profiling work attempts to impact POSIX.1. Already there are
      profile  working  groups   for  supercomputing,  transaction
      processing, real-time systems,  multi-processor systems, and
      a general multi-user this-is-what-UNIX-looks-like profile.
      I don't believe  anything should prevent a future IEEE POSIX
      standards working  group,  POSIX.42 for example,  developing
      some narrow but well defined application environment profile
      for their  application  domain which  leverages  off of  the
      POSIX.1  domain.  Implementors   will  implement  and  claim
      conformance to POSIX.42.  Applications developers will build
      portable applications using  the interfaces in  the POSIX.42
      profile. If POSIX.1  can subset carefully  enough to cleanly
      and clearly  describe  pieces of  functionality, it  should.
      Future applications  development/procurement profiles,  such
      as the U.S.  government FIPS 151-1 on POSIX.1, may indeed be
      based on  the POSIX.18  general multi-user profile.  Simple.
      But then nothing is ever simple in POSIX.



                     - 3 -



      2.  OPTIONS and options
      POSIX.1 allows implementation  variance in a number of ways.
      The  primary  implementation  options  are a  well  defined,
      explicit method of  allowing implementation variance.  These
      are all named  (e.g. _POSIX_CHOWN_RESTRICTED), and have thus
      been nick-named ``Big-O'' options.
      The  term  ``implementation   defined''  clearly  allows  an
      implementation to do anything it chooses, although there are
      documentation   requirements.   Even   ``unspecified''   and
      ``undefined''  are well  described.  Then things  get  muddy
      fast.
      Some  facilities  are  not  necessarily mandatory,  and  the
      choice of whether  to implement or  not is indicated  by the
      use of the  term ``may''. For example, an implementation may
      define certain environment  variables, and if  it does, they
      shall mean a certain thing.
      For  other   features,  an   implementation  is  allowed   a
      restricted  choice  between  two  behaviours,  indicated  by
      phrasing similar  to ``may  do A or  B''.  For example,  the
      behaviour  of  an   interrupted  read()  after  successfully
      reading some data is to either return -1 and errno is set to
      [EINTR] or the  read() returns the  number of bytes  read to
      that point.
      These  later  two  examples  are  deemed ``messy'',  by  the
      POSIX.3.1 (Test Methods  for POSIX.1) working group, and are
      being  documented.   They've   been  nick-named   ``little-o
      options'', as some  people feel they  should more explicitly
      be called out as selectable options.
      The other side of the discussion argues that these are items
      which  no  portable  application  should  care  about.   The
      wording of  the  standard allows  for the implementation  to
      choose its own  path. It acts as a caveat to the application
      developer  to  not  depend  upon  the  exact nature  of  the
      behaviour.
      This discussion will likely heat up over the next meeting or
      two.



      3.  P1201 Continues
      When  last  we   left  our  story,  the  Project  Management
      Committee  (PMC)  of   the  IEEE  POSIX   sponsor  executive
      committee (SEC) was  left to recommend  a suitable fate  for
      the P1201  project  on graphic  user interface standards.  A
      motion  had  been  made  to  withdraw sponsorship  from  the
      project.
      P1201 consists  of  two projects.  P1201.1  is developing  a
      windowing user  interface  toolkit specification.  It has  a
      long history  of bloodshed between  Open Look and  OSF/Motif
      supporters. P1201.2 is  developing a guidelines  document on
      recommended  drivability   practice.   A  style  guide   for
      ``feel'', rather than ``look''.
      Separate competing project  requests were brought forward in
      the Spring 1991,  one to standardize  the OSF/Motif API  and



                     - 4 -



      Style Guide, and  the other to standardize the Open Look API
      and Style  Guide. The IEEE  Standards Board (POSIX's  parent
      committee) considered that the functionality overlap between
      the  two proposed  work  items and  also  with the  work  of
      P1201.1,  was  an  insufficient  reason  to  refuse  project
      sponsorship.
      At the July  1991 meeting, the  POSIX working groups refused
      to undertake  sponsorship  of these  competing projects  for
      other  reasons.  The work  was  considered too  immature  to
      standardize  it.  It  was  then  moved that  sponsorship  be
      removed from P1201  because it suffers  the same flaws. This
      motion was  handed to  the PMC to  recommend action for  the
      October meeting.
      P1201.1 requested a  revision of its  scope of work,  and is
      working toward  a  simpler higher-level  API  specification.
      They have  made  real progress  over  the past two  meetings
      (July and October)  with the contentious members off chasing
      their own  project  requests. (Incidentally,  these  project
      requests are still being pursued in dank dark corners of the
      IEEE   standards   hierarchy.)    The  revised   scope   was
      recommended for approval,  and the project  will be reviewed
      again in three meetings.
      P1201.2 has been  making steady progress all along. They are
      hoping  to go  to  ballot in  the  not too  distant  future.
      Continuation of their work was recommended. P1201 is allowed
      to proceed.  It  all seemed entirely  to quiet and  straight
      forward, considering the  history of the  past two meetings.
      Maybe we're maturing.
      To pull the plug on these working groups at this point would
      be a mistake.   In a few years time, there will clearly be a
      need for such  a standard, and  the technology will  be very
      mature (read:  ripe for standardization).   It will be  very
      difficult  to  get  employers  to  support such  an  effort,
      spending the money  to keep people  involved, if the initial
      effort is closed without anything tangible to show for it.

      4.  European Meeting in October 1992
      The IEEE has  a desire, as a ``transnational'' organization,
      to have  its standards development  groups meet every  other
      year somewhere other  than the United  States. The intent is
      to gather international input into its standards development
      process.  This is  very important to  POSIX, considering its
      ISO development  stream as  an international standard  being
      developed by a  national member body. (The American National
      Standards Institute, ANSI,  delegated responsibility for the
      POSIX standard's development back to the IEEE.)
      There was a  lot of resistance  to meeting in  Europe in the
      Fall of 1992.  The problems centre around corporate approval
      and money.
      Many corporate  authorities  don't view  trips to Europe  as
      ``work''. They still think POSIX is some kind of conference.
      They don't  appreciate  that it  is a standards  development
      working group.
      Many  American  hotels,  large  enough  to support  the  350



                     - 5 -



      working group members  with about 25 to 30 meeting rooms, do
      not charge for the meeting rooms. They make their money from
      serving lunch and  coffee. European hotels apparently charge
      for meeting  rooms  regardless of  lunch and room  bookings.
      This means that  the meeting registration  will likely be at
      least twice the normal $250 US. Add to this a trans-Atlantic
      airfare, and a  higher per deum,  and managers start getting
      real uncomfortable approving the funds.
      Historically,  the  last meeting  was  held in  Brussels  in
      October, 1989. It  did not draw  a lot of European response.
      The European  response  that it did  draw was not  sustained
      past that  meeting  in many cases.  Many working groups  are
      loath to go  the effort of  gaining corporate approval for a
      European meeting, if  it's not going to bring in the desired
      European participation.
      On the other  hand, if a large European contingent does show
      up, some POSIX  working groups are concerned that their work
      agendas will be  affected, while they  adjust to bringing an
      influx of new blood up to speed on the issues.  They want to
      have their cake and eat it too.
      The current decision  is to continue  to pursue a meeting in
      Europe.  A  likely  candidate  country is  the  Netherlands.
      Ideas to defray some of the costs include:
      -- holding  seminars  prior  to  the  POSIX  working  group
        meetings on POSIX related topics,
      -- requesting  the  IEEE   Computer  Society  pick  up  the
        additional expenses, (on the order of $70,000 US.)
      -- charging individual  attendees  the additional money  to
        attend.
      I would love  to hear from  EurOpen members any suggestions,
      ideas and  preferences regarding this  subject. How high  is
      European interest in an IEEE POSIX working group meeting?

      5.  New Work Items for Consideration
      A  number  of  new  topics  are  being raised  as  potential
      candidates  for  standardization  by  the  IEEE's  Technical
      Committee on  Operating  Systems -- Standards  Subcommittee
      (TCOS-SS). This  is  the full proper  name of the  committee
      responsible for the POSIX working groups.
      Two of these candidates come from outside of the IEEE realm.
      The SPECmark  consortium  has approached  the IEEE with  the
      idea  of  making  the  SPECmark  performance  benchmarks  an
      industry standard. There may be a formal presentation by the
      SPECmark consortium  at January's  IEEE POSIX meetings,  but
      the general  feeling was that  standardization of this  work
      belonged elsewhere.
      A second  outside  proposal was from  the Rock Ridge  group.
      These people are  standardizing on an optical disk standard.
      (This work should not be confused with the ANSI X3B11.1 WORM
      standard  work. Please  see  Andrew Hume's  X3B11.1  working
      group report  in the  Jan./Feb 1992 issue  of ;login: or  in
      comp.std.unix.)  There is the desire to place a POSIX.1 file
      system on a  Rock Ridge disk,  and therefore an  interest in
      input from the POSIX working groups.  It was again felt that



                     - 6 -



      this  work  would  better  be  done  at arm's  length,  with
      appropriate liaisons in place.
      The final new  work item came  from within. The  Distributed
      Systems Steering Committee (DSSC), which overseas all of the
      network related standards in TCOS-SS, has proposed forming a
      working group to  develop a standard  for secure distributed
      computing.  Depending  upon  who  you  talk to,  this  means
      Kerberos or definitely-not-Kerberos.
      It will likely  start as a simple Birds-of-a-Feather meeting
      at  the  January  IEEE  POSIX  meeting.  If  there's  enough
      interest, a real  study group will  be formed to meet at the
      April POSIX  meeting  for the  week.  The  result of such  a
      meeting would be a project authorization request (PAR) to be
      presented to the Project Management Committee (PMC) in July.
      The  PMC  is   a  sub-committee  of  the  Sponsor  Executive
      Committee  (SEC),  which  is  the controlling  committee  of
      TCOS-SS.
      If the PMC  recommends sponsorship, the  SEC will ratify  it
      with a vote.   The study group would become a real standards
      working group of  TCOS-SS, with its  first formal meeting as
      ``early'' as the  October POSIX meeting.  Thus are standards
      born.



Volume-Number: Volume 26, Number 62

From [e-mail]  Fri Jan  3 21:26:55 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12247; Fri, 3 Jan 92 21:26:55 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20314; Fri, 3 Jan 92 21:26:47 -0500
Xref: kithrup comp.std.unix:484 comp.org.ieee:397
Newsgroups: comp.std.unix,comp.org.ieee
From: "Stephen R. Walli" <[e-mail]>
Subject: TCOS/SEC Operating Procedures
Message-Id: <[e-mail]>
Followup-To: comp.org.ieee
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Sat, 4 Jan 1992 02:04:36 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Stephen R. Walli")

In the recent ballot of the IEEE TCOS/SEC Operating Procedures,
there is the concept of an ``At-Large'' member. (There's a rude joke
in their somewhere....) Can anyone explain to me why they should exist?

``At large'' members seem to be poorly defined.
There is certainly no ``drop dead'' clause for missing a single meeting,
such as their exists against IRs.
There is no way to remove them if they're doing a bad job.
Indeed, "At-large" members have no defined role.

What is their purpose?
Why would individual IEEE professionals care about such things as
logistics (meeting locations?), or PAR approval,
or any of the other collective responsibilities of the SEC?
Yet a small number representing ONLY THEIR OWN INTERESTS
are voting members of the SEC!

There is no criteria for choosing them.
Any member of the IEEE can come forward for consideration as an at large
member,
with no written restriction to prior participation in the TCOS/SS world.
It therefore falls to the SEC to vote individuals to the positions.
It is therefore presumed that they MUST be a known figure in the TCOS/SS
world,
otherwise they have no credentials.
(There is no mention that they need to justify the reason for wanting
``At-large'' status,
even in their nomination letter.)

The hysteria that seemed to surround IRs having the vote and representing
some faceless organization with suspicious intentions seems to be missing here.
There is no requirement that this gaggle of well-meaning professionals
needs to be balanced in any way, shape, or form.

This poorly/ambiguously defined concept is too open to potential abuses.
Sounds like we're creating a POSIX patronage position. (I have no idea if
the ``patronage'' problem exists in the American government. It seems to be
the way we run the Canadian government. Sometimes referred to as the
``Pork Barrel''.)

Please enlighten me.
Stephe Walli
[e-mail]

[ Please note the followup and crossposting. -- mod ]

Volume-Number: Volume 26, Number 63

From [e-mail]  Sat Jan  4 17:56:10 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20306; Sat, 4 Jan 92 17:56:10 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03074; Sat, 4 Jan 92 17:56:08 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Standards update: Report on X3J16: C++
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Sat, 4 Jan 1992 04:04:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>...  For example, the C standard uses the
>term ``compatible type'', while the ARM uses the phrase ``the same
>type''.  The editorial changes involve using one term or the other
>consistently throughout the document.

You seem to be implying that these terms denote the same concept.
However, both terms have (distinct) meanings in the context of the
C standard.  I hope the actual "editorial" changes involve
determining which (if either) is intended for each case individually.

>...  Sensitive to the experience of
>the C committee (where a J. Hansberry invoked the formal procedures of
>ANSI to delay the publication of that standard by over a year), the
>Extensions group is going out of its way to give an unbiased hearing
>of every proposal submitted.

This seems to imply that Mr. Hansberry was not given an unbiased
hearing.  To the contrary, X3J11 bent over backward to consider
Mr. Hansberry's comments on the draft proposed C standard.  The
whole "Hansberry incident" arose when the parent administrative
body, the CBEMA X3 Secretariat, mislaid Mr. Hansberry's comments
so that they were not forwarded to X3J11 until some time after
the review process for public comments had closed and what were
thought to be the final revisions to the proposed C standard had
been made by X3J11.  Out of concern for proper consideration of
ALL properly submitted public review comments, X3J11 reopened the
review process at a subsequent meeting and Mr. Hansberry was given
the floor to explain his concerns at length.  The committee found
that approximately half of Mr. Hansberry's suggestions had already
been addressed through previous responses to other public comments,
and the remaining half were infeasible or fell outside the charter
of X3J11, so in fact no further editorial changes were required as
a result of this extension of the public comment review process.
However, X3J11 certainly would have made additional changes had
they been found necessary as a result of Mr. Hansberry's comments;
throughout the public review process I in particular, as editor of
the official documents responding to the public comments, have been
especially concerned with ensuring fairness of the process, and I
think that X3J11 did an excellent job of fairly considering EVERY
comment received during the public review of the three draft
proposed C standards.

Despite this extraordinary effort to afford his comments a fair
hearing, Mr. Hansberry exercised his right to appeal X3J11's
decisions concerning his comments.  Ultimately his appeal was
found to be groundless, but the appeal process did delay final
ratification of the C standard by nearly a year.  As best as I
could determine, Mr. Hansberry's main gripe was that X3J11 had
not added a sizeable library of extensions to make his job of
programming real-time systems easier.  We did point out that this
was not within our charter, that the bulk of the committee lacked
sufficient expertise in real-time systems, and that there was
a POSIX group tasked with working on such extensions, to which
such suggestions should be addressed, but apparently Mr.
Hansberry decided to try to force X3J11 to tackle this area.
Fortunately for the C programming community in general, the scope
of the C standard remained pretty much what it had been all along
(with the notable exception of the fairly late addition of support
for "internationalization").

>   - adding 8-bit (i.e. international) characters in
>     identifiers

As phrased, this is too narrow a view of the concept of native-
language identifiers.  X3J11 did consider this issue in considerable
detail, ultimately deciding that all that the standard should promise
would be a minimum set of characters allowed in portable programs.
Other characters can be supported as nonportable extensions, but
that seemed to be beyond the scope of a universal standard, which
necessarily must address the subset of implementation support that
can be guaranteed across ALL environments.

The one improvement that could have been made to this in the C
standard would have been to not require any diagnostic when such
extended identifiers are used in a (not strictly) conforming program.

If you guys do decide to pry open this can of worms, don't forget to
allow for multibyte character encodings (for Kanji etc.).  The idea
that all relevant natural-language characters can be encoded in a
single 8-bit scheme is extremely parochial.


Volume-Number: Volume 26, Number 64

From [e-mail]  Tue Jan  7 16:50:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24235; Tue, 7 Jan 92 16:50:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01437; Tue, 7 Jan 92 16:49:40 -0500
Newsgroups: comp.std.unix
From: dave mankins <[e-mail]>
Subject: Looking for iso/iec 9945
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Thinking Machines Corporation, Cambridge, MA (USA)
References: <[e-mail]> <[e-mail]>
Date: Tue, 7 Jan 1992 06:08:24 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (dave mankins)

In reading the checkpointing portions of IEEE 1003.10, I am told that my
checkpointing software must restore the process state ``as defined by ISO/IEC
9945''.

What is ISO/IEC 9945, and how does my library get it?

--
david mankins ([e-mail])


Volume-Number: Volume 26, Number 66

From [e-mail]  Tue Jan  7 16:53:27 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24360; Tue, 7 Jan 92 16:53:27 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01518; Tue, 7 Jan 92 16:49:48 -0500
Newsgroups: comp.std.unix
From: Shane McCarron <[e-mail]>
Subject: your IR issue comments (fwd)
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 6 Jan 1992 13:34:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

I received the following from the POSIX Chair, Jim Isaak.

Forwarded message:

Shane,
    I believe your recomended resolution for limiting the IR
voting members is responsive to the concern raised in the balloting
that IR's might dominate the SEC voting membership.  In effect your
suggesting that only IR's can fill the 20% "at large" seats, and that
other interested parties must seek some other voting position (like
a SEC officer or WG chair).

    However, most of your assertions in your distributed note were
not focused at this point, and many were misleading or in-correct.

    I would ask you to consider my comments below, and if you
agree, distribute a corrective note to the same distribution list as
your initial comments.  (I have no problem with your objective or
conclusion, only the retoric used in promoting it).

1. IR's are not limited to user organizations, vendor consortia and
    other groups are welcome as well.

2. Representation of individuals and organizations in POSIX does NOT
    typically include SEC voting membership.  As such, the IR's
    without an SEC vote have as much voice (more actually) than
    an individual that participates directly.

3. Any attendee or written submission can speak for an organization.
    This is NOT prohibited, it is allowed, and at times, encouraged.
    For example, we have had formal positions from AT&T, IBM, and
    NIST represented at times that I can recall off hand.  And at
    times we specifically ask someone to speak (if they are authorized
    to do so) for their organization.

4. If we fail to listen to IR's at the SEC level, that is a cause for
    great concern.  I hope that voting membership in the SEC is not
    needed, since the 20% you propose will not allow all the current
    IR's to hold such status.

    If we are failing to do this, the issue should be raised as high
    as needed to correct the situation ("listen" does not mean "agree",
    but it does mean understand and have rational response.)

    [we have 40 identified voting members of the SEC, with 10
     IR's, assuming SPARC International is accepted at the Jan.
     meeting; that is 25%.]

5. The general public ability to attend and participate in the SEC voting
    activity is not affected by the IR voting status.  The public is
    welcome to attend or send in written input, but not to vote.
    Those individuals and organizations that are members of IR groups,
    (DEC is a member of 6 or 7 of the SEC IR's...) will lose that
    specific vote in the SEC, although the IR could obtain a voting
    position via the "Member at large" pool, becoming an SEC officer,
    or a steering committee or working group chair.

    Your proposal does not identify a way to maximize the overall
    representation of constituancies that are not represented in
    the SEC otherwise.  Nor is it clear that this is the objective.


6. It is not clear why allocating the limited % of voting seats to
   some "IR's" as opposed to "Members at large"  might cause a loss of
   industry support for the POSIX work.  But that would be a serious
   problem if it were to occur.




--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]

Remember - only Nixon could go to China.

Volume-Number: Volume 26, Number 68

From [e-mail]  Tue Jan  7 16:53:26 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24359; Tue, 7 Jan 92 16:53:26 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01373; Tue, 7 Jan 92 16:49:31 -0500
Newsgroups: comp.std.unix
From: "Shane P. McCarron" <[e-mail]>
Subject: POSIX REPRESENTATION IN JEOPARDY
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UNIX International
Date: Thu, 2 Jan 1992 21:05:12 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Let me start this message by saying something inflammatory:

YOU ARE IN DANGER OF LOSING YOUR REPRESENTATION AT POSIX!!!

There are two forces at work which are limiting the participation of
the user community in the definition of industry standards.  The first
is the world-wide recession.  This is having a serious effect on the
ability of representatives from small organizations to participate in
POSIX.  This was especially obvious at the October meeting, when many
long time participants from small organizations which use open systems
did not attend or indicated that they may not attend in the future.

Fortunately, to date there has been a method whereby user groups could
represent their members within the POSIX committees.  Whether you knew
about it or not, many not-for-profit organizations have a special
status within POSIX.  This status, called Institutional Membership,
basically allows a designated representative from a not-for-profit
organization to speak for that organization, instead of speaking as an
individual (normally people in IEEE standards activities CANNOT speak
for their companies).  Further, people who speak for organizations have
traditionally been listened to very carefully, as their input
represents a potentially broad base of the standards' eventual users.

Unfortunately, there is a second force at work.  Recently there has
been a move afoot to deprecate the value of the Institutional Member
status within POSIX.  This is taking the form of changes to the IEEE
TCOS/SS SEC procedures document as it is going through ballot.  The
most recent of these changes removes Institutional Member
representatives' right to vote in the POSIX Sponsor Executive Committee
(SEC) - the group that oversees all POSIX activities.

As a long time member of the POSIX community, and as an employee of a
company that has Institutional Member status within POSIX, I feel that
these changes could severely damage the ability of the general public
to participate in open systems standards.  Further, I am concerned
that the changes may reduce the amount of industry support for the
various POSIX standards that are now being written.

What can you do?  If you or your company are a member of one or more of
the organizations who may lose status with POSIX, you should write to
the SEC Chair and your representative(s) and let them know that you are
concerned.  Further, you _could_ submit an endorsement of my objection
on the draft procedures.  The pertinent portion of that ballot and the
contact information for the TCOS/SEC Chair and the Institutional Member
representatives are included below.

NOTE:  If you are a member of the TCOS/SS procedures balloting group,
please DO NOT include this objection in your ballot.  If you support
the objection, merely cite it in your ballot.

Thanks for your attention in this important matter.  If you have any
questions, don't hesitate to contact me.

-----  contact information  -----

The TCOS/SEC Chair's address is:

    James D. Isaak
    IEEE TCOS/SS Chair
    Digital Equipment Corporation
    TTB1-5/G06
    10 Tara Blvd
    Nashua, NH  03062

    [e-mail]

Organizations currently having Institutional Member status within POSIX
include:

DECUS

    Loren Buhle
    DECUS Representative to TCOS/SEC
    University of Penn.
    Rm 440A
    3401 Walnut Street
    Philadelphia, PA  19104

    [e-mail]

EurOpen

    Stephen Walli
    EurOpen Representative to TCOS/SEC
    572 Foxrun Court
    Oshawa, Ontario L1K 1N9
    CANADA

    [e-mail]

OSSWG

    CDR Greg Sawyer
    OSSWG Representative to TCOS/SEC
    Space and Naval Warfare Systems Command
    SPA WAR 2312B2
    Washington, DC  20363

Open Software Foundation

    John Morris
    OSF Representative to TCOS/SEC
    Open Software Foundation
    11 Cambridge Center
    Cambridge, MA  02142

    [e-mail]

SHARE

    Richard Alexander
    SHARE Representative to TCOS/SEC
    315CCC
    Cornell University
    Ithaca, NY  14853

    [e-mail]

UNIX International

    Jack Bissell
    UI Representative to TCOS/SEC
    UNIX International
    20 Waterview Blvd.
    Parsippany, NJ  07054

    [e-mail]

UniForum

    Ralph Barker
    UniForum Representative to TCOS/SEC
    UniForum
    Suite 201
    2901 Tasman Drive
    Santa Clara, CA  95054

    [e-mail]

Usenix

    Peter Collinson
    Usenix Representative to TCOS/SEC
    Hillside Systems
    61 Hillside Avenue
    Canterbury CT2 8HA
    ENGLAND

    [e-mail]

X/Open

    Derek Kaufman
    X/Open Representative to TCOS/SEC
    X/Open
    Suite 380
    1010 El Camino Real
    Menlo Park, CA  94025

    [e-mail]

-----  my objection  -----

@ Section 12 page 28 lines ALL objection

Problem:

    The definition of Institutional Membership, and the
    requirements for that membership, are excellent.  However,
    representatives of these members must be allowed to vote at
    the TCOS/SEC meetings in order to ensure several things:

    1)    The Institutions approved by the SEC must represent
        some critical segment of the industry, or their
        membership would not have been approved.  As a
        representative of that segment, the institution must
        be allowed to make motions to the SEC and to voice
        their opinions.  Only voting members may make motions.
        The TCOS/SS must ensure that the entire industry is
        able to fully participate in the open systems
        standards process.

    2)    Many Institutions are currently funding their
        representatives because of their voting status.  The
        Institutions recognize that this status gives their
        entire membership a powerful voice in the
        standardization process.  Loss of this status may
        cause some Institutions to re-evaluate their
        participation in TCOS.  The TCOS/SS must ensure that
        all Institutions who have found it in their best
        interests to participate to date continue to
        do so.

    3)    Institutional Members and the membership of those
        institutions are a unique resource.  Members enable the
        TCOS working groups to have access to a broader range of
        reviewers by forwarding pertinent working documents to
        people who otherwise might not see those documents.  They
        further help TCOS to create broader industry buy-in to TCOS
        authored standards.  The TCOS/SS must ensure that
        this resource is not lost.

    4)    Institutional representatives are also an important
        resource to the TCOS/SEC.  These representatives often
        do not have specific roles within TCOS (unlike working
        group chairs).  Because of this, they are often able
        to participate in subcommittees, drafting committees,
        and act in positions of authority.  This human
        resource is essential to the continued success of
        TCOS.  The TCOS/SS must ensure that this human
        resource continues to be available.

Action:

    Change section 12.3 to indicate that Institutional Members are
    voting members of the SEC.

    Change section 12.1 to indicate that the total number of
    Institutional Members cannot exceed 20% of the members of the
    TCOS/SEC.  (This should allow all current Institutional Members
    to continue to participate, and because of the strict rules
    about consecutive participation will virtually guarantee their
    continued activity within TCOS.  Further, as TCOS grows the
    number of Institutional Members can grow.)
--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]

Remember - only Nixon could go to China.


Volume-Number: Volume 26, Number 65

From [e-mail]  Tue Jan  7 17:21:31 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27531; Tue, 7 Jan 92 17:21:31 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01447; Tue, 7 Jan 92 16:49:42 -0500
Newsgroups: comp.std.unix
From: David Moore <[e-mail]>
Subject: Use of POSIX and X/Open Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: David Moore <[e-mail]>
X-Submissions: [e-mail]
Organization: DATA SCIENCES Wilmslow Manchester UK
Date: Tue, 7 Jan 1992 13:06:51 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Does anyone have any experience of applications development using POSIX
interfaces only? Is it possible to write interactive applications for
a commercial environment using only these interfaces?

Further, does anyone have any experience of applications development using
X/Open interfaces (XPG3) only and then porting the developed applications
to a variety of platforms of types that are different from the development
environment?

I would be very grateful if anyone can relate (by e-mail please) their
experiences in using interface standards and/or porting between environments
which support POSIX and/or X/Open interface sets.

Thanks in anticipation

David Moore



Volume-Number: Volume 26, Number 67

From [e-mail]  Wed Jan  8 18:22:05 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01345; Wed, 8 Jan 92 18:22:05 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04178; Wed, 8 Jan 92 18:22:02 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 8 Jan 1992 23:12:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Sean Fagan writes:
> You bring up the concept of pipes, which didn't exist as files in the
> original systems.  Well, a lot of things weren't in the original systems
> originally, either, and lots of people seem to think that some of the
> additions since V7 were a good idea.

But pipes *still* aren't in the filesystem in any popular UNIX variant.
The proponents of super-open() seem to want to be able to create new
files, new TCP connections, and so on with a single system call. *How is
open() going to create new pipes*? If you can't answer this question
then you don't really support the ``everything should be in the
filesystem'' philosophy. (I certainly can't answer it.) If POSIX invents
an answer then what's the chance it'll find the best technical solution?

> But a named TCP/IP socket,
> to a specified host, would be nice.  (E.g., cp
> /tcp/ip/ftp/uunet.uu.net/ftp/ls-lR.Z .)

So put it into your shell! There's nothing stopping you. tcsh sources
are freely available.

> Can you come up with a good reason (excluding efficiency, which
> I'll mention in a bit) *not* to support the creation a named pipe in the
> filesystem, forking, and then unlinking it, but keeping it open?

How about this: Pipes don't belong in the filesystem. Some UNIX variants
swap pipes out to disk, but most don't. What if you don't have a
directory available for the mknod()? Implementing pipe() on top of
mknod() is dangerous! Anyway, I don't think named pipes are really
relevant to the discussion; you don't create a *new* pipe through the
filesystem when you open() a named pipe.

> The question is:  is this amount of generalization worth it?  I'm not sure.

The question is: Has this amount of generalization appeared in any
popular UNIX system, let alone a sufficient number of systems that we
can honestly call it an industry standard?

> Tell me, Dan, how do you feel about the /dev/fd filesystem/pseeudo devices?

I think they're well-done kludges to deal with non-UNIXy programs: i.e.,
programs which think that everything's a file. /dev/fd brings those
programs in line with the real philosophy: everything's a file
*descriptor*.

Imagine a shell syntax analogous to <$(program) which produces just a
descriptor number---3 instead of /dev/fd/3. This is trivial to
implement. Then imagine that the non-UNIXy programs are rewritten to
take file descriptor arguments instead of filename arguments. This, too,
is trivial to implement. Result: You get all the advantages of ksh's use
of /dev/fd, *but you don't need a single kernel change to implement it*.

Perhaps you're right. Perhaps super-open() would make life simpler for
UNIX programmers. But I don't see anything it can do which file
descriptors can't do in combination with well-written utilities. I am
disgusted at the idea that POSIX members ``expect'' super-open() to be
``standardized.'' Where's the history of failures and successes in
solving the problem (if there even is a problem!) of opening files?

---Dan


Volume-Number: Volume 26, Number 69

From [e-mail]  Wed Jan  8 19:00:09 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06370; Wed, 8 Jan 92 19:00:09 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11203; Wed, 8 Jan 92 18:44:31 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 8 Jan 1992 23:31:16 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Peter da Silva writes:
> Because the more things you can access via the open() system call, the more
> powerful an environemnt you have. For example, older programs become able to
> access more data sources and sinks without modification or recompiling.

No. If you need a kludge to support non-UNIXy programs, use /dev/fd.
It's vastly simpler than any super-open() could ever be, and it achieves
your goal of letting older programs open network connections et al.

> For a concrete example, in AmigaDOS this expectation is taken further:

Fine. If you think that AmigaDOS features are appropriate for POSIX
standardization, then implement them in a UNIX system and wait for their
obvious advantages to win everyone over.

> > Let's move on to the supposed simplicity of super-open() for programmers.
> > Since when was it difficult to create, e.g., network connections with the
> > BSD syscalls?
> Not very, but it's hard to create one from your ".mailrc" file.

Hmmm? There are many programs running around (e.g., clientserver) which
do the same thing for network connections that the shell (via < and >)
does for the filesystem.

> > also bloating the kernel for something which the vast majority of
> > programs will never use.
> The challenge is on... let's look though my System III (because it's older
> and therefore more "pure") Xenix manual:
> accton, awk, bdiff, bfs, chgrp, chmod, chown, cmp, comm, cp, cron, cu, diff,
> diff3, ed, finger, join, ln, look, lpq, lpr, mail, make, more (and less),
> mv, nohup, pr, rm, sdiff, tee, touch, and uucp (etc).

bdiff, cmp, comm, diff, diff3, join, look, more, nohup, pr, sdiff, tee,
and touch can be written to work with file descriptors under v7. Under
BSD, the syscalls for working with descriptors are more complete, so you
can do chgrp, chmod, chown, etc. without explicit filenames. I also
wonder what sense it makes to do a chmod on /dev/tcp/uunet.uu.net/ftp---
how are you going to keep track of the modes on *every single possible
network connection*? Where's your implementation which shows us what the
issues are?

Three of the programs you list---ln, mv, rm---are red herrings: of
course they work with filenames in the filesystem, because their job is
to manipulate those names! (They fall under the category of ``a few
specialized tools'' that I mentioned.) And do you have a system where
accton works over the network? If so I'm sure crackers love your system.

finger, lpq, lpr, mail, and uucp are (relatively) complex tools for
accessing system databases. Fortunately, they can all be written as
combinations of simpler tools, some of which are dedicated to opening
files and some of which stick to file descriptors. That's the UNIX way.

Finally, I have to agree with you that awk, ed, and make would have a
tough time without open(). Like sh, they're all programming languages,
and like sh they make it very easy for the programmer to open a file.
So maybe super-open() would make these tools more useful. I doubt it.
For the same reason that they're powerful enough to open files, they're
powerful enough to execute arbirtary programs, and those arbitrary
programs could open network connections just as easily as open() could.

> This list also
> brings up the question of security: all UNIX security is based on access to
> files. Adding new ways to create file descriptors involves duplicating all
> this security and causing a separate source of kernel expansion.

Hardly. Adding new ways to create file descriptors involves thinking up
new ways to deal with security. Filesystem security is utterly
inappropriate for network connections, for example. Adding a
super-open() means kludging these new security mechanisms into a
protection system designed only for files.

> > Finally, let's consider super-open()'s advantages for users. Certainly
> > it'd be nice for a user to be able to type something like, say,
> >    % cat #[e-mail]
> More like "cat /dev/telnet/athena.mit.edu/13".

Whatever. The shell can still do it!

> then what do you do when you want to access this from "awk", or create a
> (sumbolic) link to it called "/dev/weather"?

The pure solution is to have every program keep a file descriptor around
for talking to the shell. Then requests for opening files can be
shuttled down that descriptor. The problem reduces once again to a small
matter of shell programming.

Less pure solutions involve /dev/fd or perhaps what Convex calls
``watchdogs.'' Both of these are far cleaner mechanisms than
super-open(), and since they've at least been considered by the market,
they'd be far more appropriate for standardization.

---Dan

[ Apologies to anyone who has seen multiple copies of Dan's postings. -- mod ]

Volume-Number: Volume 26, Number 70

From [e-mail]  Wed Jan  8 19:18:20 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06836; Wed, 8 Jan 92 19:18:20 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18674; Wed, 8 Jan 92 19:18:16 -0500
Xref: kithrup comp.std.unix:492 comp.unix.internals:2799
Newsgroups: comp.std.unix,comp.unix.internals
From: Sean Eric Fagan <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Followup-To: comp.unix.internals
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: Kithrup Enterprises, Ltd.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 8 Jan 1992 23:38:22 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>But pipes *still* aren't in the filesystem in any popular UNIX variant.

You mean like xenix?  (200k installed systems, as far as I know, all of them
have named pipes.  SunOS has named pipes; SysV has named pipes.  Which of
these is not "popular" by your definition, Dan?)

>The proponents of super-open() seem to want to be able to create new
>files, new TCP connections, and so on with a single system call. *How is
>open() going to create new pipes*?

How is open() going to create a directory?

>So put it into your shell! There's nothing stopping you. tcsh sources
>are freely available.

That doesn't help any other case, Dan.  Such as a program wanting to open up
a connection to some other site.  I guess you're advocating using popen()
instead of open for every case, right?  (After all, you can do

    FILE *fp = popen ("cat < file", "r");

instead of using open() or fopen() directly, right?)

>How about this: Pipes don't belong in the filesystem.

Circular arguments are pretty weak for someone as bright as you, Dan.  You
are welcome to argue that pipes don't belong in the filesystem because they
don't belong there, but you won't win many debates or arguments that way.

>What if you don't have a
>directory available for the mknod()?

What if you don't have a directory available for any open()?  *Gasp*!  You
may have to use tmpnam()!  Will the world survive this?

>Anyway, I don't think named pipes are really
>relevant to the discussion; you don't create a *new* pipe through the
>filesystem when you open() a named pipe.

That's nice.  You used to not be able to create a new file when you open()ed
it, either; that's what creat() was for, remember?  How long was it before
BSD had a version of open() that would create the file if desired?

>The question is: Has this amount of generalization appeared in any
>popular UNIX system, let alone a sufficient number of systems that we
>can honestly call it an industry standard?

Plan 9.  Version 8.  BSD 4.4 will probably have a /proc, SysVr4 already
does.  SunOS, 4.4, SysVr4 all have the means to support this type of
generalization, and someone, at some point, will probably write a "network
filesystem" (not NFS, but of the type "/network/host/port") for one or more
of them.

There was a proposal, a year or so ago, to create a 'fdlink()' system call,
that would create a name in the filesystem for any given file descriptor.
At the time, I was against it, as the description was vague enough and I
didn't see the advantage.  I've since relaxed my position a bit:  I can
understand the use for it, and even see some things that you cannot do
without it.

This is, as Dan stated, getting away from the topic.  I'm going to crosspost
to comp.unix.internals and set followups there.

--
Sean Eric Fagan
[e-mail]

Volume-Number: Volume 26, Number 71

From [e-mail]  Thu Jan  9 15:24:43 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14411; Thu, 9 Jan 92 15:24:43 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10939; Thu, 9 Jan 92 15:24:40 -0500
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Use of POSIX and X/Open Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Thu, 9 Jan 1992 17:51:27 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (David Moore) writes:
>Does anyone have any experience of applications development using POSIX
>interfaces only? Is it possible to write interactive applications for
>a commercial environment using only these interfaces?

Sure, a rich enough set of UNIX functionality was included in 1003.1 to
support all kinds of applications.  However, 1003.1 doesn't include the
curses library, for example, so if that's what you want you have to either
require more than 1003.1 be provided on the target system or else implement
your own version of the additional functionality.  These days, X11 may be
more important to require, and it is not yet specified by a POSIX standard.

>Further, does anyone have any experience of applications development using
>X/Open interfaces (XPG3) only and then porting the developed applications
>to a variety of platforms of types that are different from the development
>environment?

XPG is essentially SVID with extensions, so if you steer clear of the
extensions you should be able to port to any modern System V implementation.
However, in that case you might as well use SVID as a guide.  Fortunately,
SVID, XPG, AES, and POSIX.1 are substantially in agreement these days and
therefore if you don't use features specific to just a proper subset of
them your code should be widely portable.  The problems arise primarily
when porting to systems based on 4.[23]BSD without System V enhancements.


Volume-Number: Volume 26, Number 72

From [e-mail]  Thu Jan  9 15:24:46 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14421; Thu, 9 Jan 92 15:24:46 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10947; Thu, 9 Jan 92 15:24:44 -0500
Newsgroups: comp.std.unix
From: Keld J|rn Simonsen <[e-mail]>
Subject: Re: Standards update: Report on X3J16: C++
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]>
Date: Tue, 7 Jan 1992 21:40:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Keld J|rn Simonsen)

>>   - adding 8-bit (i.e. international) characters in
>>     identifiers

ISO SC22/WG14 C programming language WG is also addressing this issue.

We have discussed it and we would prefer a solution based on a
classification of admissible characters in the locale.

We see that there might be problems with it, such as security
problems, that must be adressed in a solution. Doug Gwyn has
called the international characters in identifiers "a can of worms"
and I would appreciate if he or others would describe what problems
they want to be addressed in such a proposal. Either post to
the list, or mail me, and I will summarize.

Keld Simonsen
Danish member of WG14
[e-mail]


Volume-Number: Volume 26, Number 73

From [e-mail]  Thu Jan  9 15:24:52 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14439; Thu, 9 Jan 92 15:24:52 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10956; Thu, 9 Jan 92 15:24:49 -0500
Newsgroups: comp.std.unix
From: Karl Kleine <[e-mail]>
Subject: Re: Looking for iso/iec 9945
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Reply-To: '[e-mail]'
X-Submissions: [e-mail]
Organization: Forschungszentrum Informatik, Karlsruhe
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Wed, 8 Jan 1992 20:08:56 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Karl Kleine)

In article <[e-mail]>, [e-mail] (dave mankins) writes:
|> In reading the checkpointing portions of IEEE 1003.10, I am told that my
|> checkpointing software must restore the process state ``as defined by ISO/IEC
|> 9945''.
|> What is ISO/IEC 9945, and how does my library get it?

The full-blown title is (deep breathing...)

    ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990), Information technology --
    Operating System Interface (POSIX) -- Part 1: System Application
    Program Interface (API) [C Language]

Among non-iso-ists this is generally known as POSIX.1 or P1003.1, the
original IEEE reference names. You can get copies by your national standard
body, which usually distributes ISO standards in your country, or by the
IEEE computer society, which I find at least for Europe much more convenient
(and cheaper). In Europe you call [phone], in the US [phone]
for the IEEE path, or try ANSI sales at [phone].

--
Karl Kleine                        email [e-mail]
FZI Forschungszentrum Informatik            phone [phone]
Haid-und-Neu-Str. 10-14, D-7500 Karlsruhe, Germany    fax   [phone]


Volume-Number: Volume 26, Number 74

From [e-mail]  Thu Jan  9 18:23:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13377; Thu, 9 Jan 92 18:23:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24189; Thu, 9 Jan 92 18:23:22 -0500
Xref: kithrup comp.std.unix:496 comp.unix.internals:2818
Newsgroups: comp.std.unix,comp.unix.internals
From: peter da silva <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Followup-To: comp.unix.internals
Originator: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 9 Jan 1992 21:52:52 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

I think Dan has a couple of basic problems in his argument here: first,
looking at extensions to the file system as extensions to "open"; and
second, missing the huge amount of code that comprises the "normal" UNIX
environment that depends on a uniform name space. Because of this uniform
name space, you can change the behaviour of a program (which may well be
a shell script) by changing the name of a file.

For the first of these problems, it's not just "open" that operates on
files.  It's "creat", "mknod", "link", "chmod", and so on. All these
calls have to be expanded, duplicated, or replaced. Or you can simply go
down a level of indirection and change "namei"... and, in fact, virtually
every version of UNIX has done this in one way or another. The
"watchdogs" that he refers to are one implementation of what he's arguing
against.

If this namespace is splintered by creating a whole bunch of different
methods of opening streams, then you lose this capability. You suddenly
need to coordinate with the shell ever time you want to refer to a
file... the shell actually becomes the "super open" Dan's complaining
about.

Correspondingly, if this namespace is strengthened by adding new types of
streams to it, the system becomes more powerful. As an *example* of this,
I brought up AmigaDOS: which has taken this basic concept and extended
it. In fact, many of the AmigaDOS facilities have been copied from UNIX.

Another problem with Dan's suggestions is that they reduce the name space
available for normal files: a name space that's already hurt by the UNIX
option syntax. If you start defining "3" to mean file descriptor 3,
you're going to run into problems if you "cd /usr/spool/news/comp/std/unix"
and then type "more *". If you make that "#3", then the namespace
collision gets less critical, but it's still a problem. This is basically
what MS-DOS does with the special file names "CON", "PRT", and so on...
and it gets real old real fast.

We also have some red herrings, but I think Sean has pretty well
addressed them already in his posting. One he missed is this:

    "How about this: Pipes don't belong in the filesystem. Some
    UNIX variants swap pipes out to disk, but most don't."

Whether a pipe is implemented using disk blocks or not is a completely
separate concept from whether it's visible in the file system.

[ Ok.  I am posting this here because it is attempting to discuss a basic
  philosophy of UNIX et al.  Once again, I have crossposted this to
  comp.unix.internals, and set followups there. -- mod ]

Volume-Number: Volume 26, Number 75

From [e-mail]  Tue Jan 14 14:52:06 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14265; Tue, 14 Jan 92 14:52:06 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23140; Tue, 14 Jan 92 14:52:04 -0500
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Thu, 9 Jan 1992 16:46:53 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

Dan Bernstein writes:
> bdiff, cmp, comm, diff, diff3, join, look, more, nohup, pr, sdiff, tee,
> and touch can be written to work with file descriptors under v7. Under
> BSD, the syscalls for working with descriptors are more complete, so you
> can do chgrp, chmod, chown, etc. without explicit filenames.

I don't see a fundamental conflict between making these programs
work with file descriptors (actually, `handles') and wanting a
naming scheme where every object of interest can be accessed by
a name.  Not every file operation makes sense on every object but
that is okay.  Just as write() to a directory does not make sense,
chmod() of a network connection does not either.  Naming is
orthogonal to what operations make sense on an object or even,
whether the object is long-lived or temporary.

What many people (including me) are saying is that we want to
access more kinds of objects than those provided by a traditional
unix filesystem and we want a unified approach to accessing these
objects.

This does not mean implementing all of these new mechanisms in the
unix kernel.  Far from it.  Any one should be able to attach a
name-space object (a directory, but that has taken on too specific
a meaning) into the existing naming hierarchy.  Not all objects
may be directly named in a given namespace (e.g. the namespace of
internet services) but so what?

I agree with Dan that the existing file protection system is not
appropriate for network connections and that a more general scheme
needs to be worked out; but it does not invalidate the usefulness
of a uniform naming hierarchy.

> The pure solution is to have every program keep a file descriptor around
> for talking to the shell. Then requests for opening files can be
> shuttled down that descriptor.

Replace the `shell' with the root of the naming tree and we are in
agreement!  Given that any one can use any `shell' we can't depend
on having a specific shell around.  Besides, the job of a shell is
to interpret user commands; it should not be in the business of
implementing super-open -- UNIX philosophy(tm), you know :-)

-- Bakul Shah
[e-mail]           or          ..!uunet!amdcad!light!bvs


Volume-Number: Volume 26, Number 76

From [e-mail]  Tue Jan 14 14:52:12 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14279; Tue, 14 Jan 92 14:52:12 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23159; Tue, 14 Jan 92 14:52:09 -0500
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: Peter da Silva <ficc!peter>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 9 Jan 1992 17:31:41 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> Peter da Silva writes:
> > Because the more things you can access via the open() system call, the more
> > powerful an environemnt you have. For example, older programs become able to
> > access more data sources and sinks without modification or recompiling.

> No. If you need a kludge to support non-UNIXy programs, use /dev/fd.

You say it's a kludge to support non-UNIXy programs. I say it's a natural
extension to the existing file system to enhance normal, conventional, UNIX
programs.

> > For a concrete example, in AmigaDOS this expectation is taken further:

> Fine. If you think that AmigaDOS features are appropriate for POSIX
> standardization, then implement them in a UNIX system and wait for their
> obvious advantages to win everyone over.

A lot of them are *copied* from UNIX systems to AmigaDOS, for example the
(initially third-party, and freeware) PIPE: and RDF: devices.

> > Not very, but it's hard to create one from your ".mailrc" file.

> Hmmm? There are many programs running around (e.g., clientserver) which
> do the same thing for network connections that the shell (via < and >)
> does for the filesystem.

I see, and how do you specify them to a program that expects a filename?

> > > also bloating the kernel for something which the vast majority of
> > > programs will never use.
> > The challenge is on... let's look though my System III (because it's older
> > and therefore more "pure") Xenix manual:
> > accton, awk, bdiff, bfs, chgrp, chmod, chown, cmp, comm, cp, cron, cu, diff,
> > diff3, ed, finger, join, ln, look, lpq, lpr, mail, make, more (and less),
> > mv, nohup, pr, rm, sdiff, tee, touch, and uucp (etc).

> bdiff, cmp, comm, diff, diff3, join, look, more, nohup, pr, sdiff, tee,
> and touch can be written to work with file descriptors under v7.

Yes... at the dual cost of spending time doing it, and reducing their
utility in conventional shell scripts.

> Under
> BSD, the syscalls for working with descriptors are more complete, so you
> can do chgrp, chmod, chown, etc. without explicit filenames. I also
> wonder what sense it makes to do a chmod on /dev/tcp/uunet.uu.net/ftp---

It makes sense to chmod /dev/tcp, though. Or /../xds13.

As for mv, rm, cp, etcetera... you need to re-invent those tools for each
new name space you create (and deal with conflicts: is "3" a file name, a
file descriptor number, or an IP port number?).

> And do you have a system where
> accton works over the network?

Yes, you can specify a file on a remote machine.

> If so I'm sure crackers love your system.

Not really. Our network, as far as possible, looks like a single computer.
Permissions are mirrored across it. It's as secure as a single, larger
machine would be.

> Hardly. Adding new ways to create file descriptors involves thinking up
> new ways to deal with security. Filesystem security is utterly
> inappropriate for network connections, for example.

Expand?

> > > Finally, let's consider super-open()'s advantages for users. Certainly
> > > it'd be nice for a user to be able to type something like, say,
> > >    % cat #[e-mail]
> > More like "cat /dev/telnet/athena.mit.edu/13".

> Whatever. The shell can still do it!

The shell can't do it for "cc" or "make".

> > then what do you do when you want to access this from "awk", or create a
> > (sumbolic) link to it called "/dev/weather"?
>
> The pure solution is to have every program keep a file descriptor around
> for talking to the shell. Then requests for opening files can be
> shuttled down that descriptor. The problem reduces once again to a small
> matter of shell programming.

I see. The shell becomes the "super open" with its own address space. And
you don't get a uniform namespace across applications. You have all the
disadvantages you've claimed for a "super open", and none of the advantages.

> Less pure solutions involve /dev/fd or perhaps what Convex calls
> ``watchdogs.'' Both of these are far cleaner mechanisms than
> super-open(), and since they've at least been considered by the market,
> they'd be far more appropriate for standardization.

"watchdogs" *are* an implementation of what I'm talking about.
--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"
-- grep -il 'sig.*virus' $*|xargs sed -n '/^-- /,$p'|post -n alt.fan.warlord


Volume-Number: Volume 26, Number 77

From [e-mail]  Tue Jan 14 15:00:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16932; Tue, 14 Jan 92 15:00:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25029; Tue, 14 Jan 92 14:59:59 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 11 Jan 1992 11:39:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Sean's right that discussions of possible future extensions to UNIX
don't belong anywhere near comp.std.unix, so I'll stick to the points
relevant to standardizing a super-open(). To review the main issue: Many
POSIX members seem to think that POSIX should standardize a version of
open() which can open network connections. I find this position utterly
ridiculous. I once again accuse POSIX of standardizing inventions which
nobody has implemented, let alone tried on the market.

Sean writes:
> In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> >But pipes *still* aren't in the filesystem in any popular UNIX variant.
> You mean like xenix?  (200k installed systems, as far as I know, all of them
> have named pipes.

Please read what I wrote. As I said before, open() doesn't let you
*create* a pipe in any popular UNIX variant. Named pipes are *not* new
pipes. To create a named pipe you need mknod() (or POSIX mkfifo()).

  [ network connections ]
> >So put it into your shell! There's nothing stopping you. tcsh sources
> >are freely available.
> That doesn't help any other case, Dan.  Such as a program wanting to open up
> a connection to some other site.  I guess you're advocating using popen()
> instead of open for every case, right?

As I said before, tools like sh and editors are powerful enough to open
programs as well as files. vi already calls the shell automatically if
it sees any special characters; if you gave your shell a syntax for
network connections, vi would automatically use that syntax. Less
powerful utilities don't need to open network connections any more than
they need to open files; they can stick to file descriptors.

> >The question is: Has this amount of generalization appeared in any
> >popular UNIX system, let alone a sufficient number of systems that we
> >can honestly call it an industry standard?
> Plan 9.  Version 8.  BSD 4.4 will probably have a /proc, SysVr4 already
> does.

/proc is not the same as a super-open(). I have no objection to POSIX
documenting features which the industry has agreed on. The industry has
not agreed on an open() which can create network connections. Period.

> There was a proposal, a year or so ago, to create a 'fdlink()' system call,
> that would create a name in the filesystem for any given file descriptor.

May I remind you that I was one of the proponents of that syscall? And
that it was only supposed to work for regular files which were already
stored in the same filesystem, for the same reason that link() only
works for names in the same filesystem?

---Dan

[ To save everyone a lot of anguish:  Dan, most people here haven't
  argued that open() should create things, such as network connections.
  But we are arguing that it fits the unix model to have them in the
  filesystem's namespace; if you are not against /proc, you cannot be
  against /tcp or /net or whatever it decides to be called, as they are
  essentially the same thing:  using the namespace to get at things
  normally only accessible through twisted mazes.  Both cases put some
  (or all) of the work onto the filesystem (be it in the kernel, a user-
  process, or whatever). -- mod ]

Volume-Number: Volume 26, Number 78

From [e-mail]  Tue Jan 14 15:01:02 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17066; Tue, 14 Jan 92 15:01:02 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25096; Tue, 14 Jan 92 15:00:08 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: Use of POSIX and X/Open Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]>
Date: Sat, 11 Jan 1992 22:27:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Doug writes:
> XPG is essentially SVID with extensions, so if you steer clear of the
> extensions you should be able to port to any modern System V implementation.
> However, in that case you might as well use SVID as a guide.  Fortunately,
> SVID, XPG, AES, and POSIX.1 are substantially in agreement these days and
> therefore if you don't use features specific to just a proper subset of
> them your code should be widely portable.  The problems arise primarily
> when porting to systems based on 4.[23]BSD without System V enhancements.

Huh? If you stick to the intersection of all of those standards, there's
very, very little you can do which won't work on BSD. The problems arise
primarily when you take a program which depends on networking, or
reliable signals, or job control, or select(), and try to port it to
systems based on System V without BSD 4.[23] enhancements. You imply
that BSD without System V features is limited, when in practice the
exact opposite is true.

If, on the other hand, you don't restrict your view of POSIX to features
which were already set in stone by the SVID, then you begin to see quite
a few BSD-specific features (like reliable signals), as well as some
inventions which don't correspond to *any* de facto standard (like POSIX
job control). So much for using ``standards'' to make your code
portable. I'd rather continue to write code which works on real systems,
thank you very much.

---Dan

Volume-Number: Volume 26, Number 80

From [e-mail]  Tue Jan 14 15:01:03 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17065; Tue, 14 Jan 92 15:01:03 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25053; Tue, 14 Jan 92 15:00:04 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 11 Jan 1992 12:25:11 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Let me quickly mention an alternative to super-open(): namely, pdopen(),
which is called as (e.g.) pdopen("openin","foo",O_RDONLY) and returns a
file descriptor for reading from foo. Internally pdopen() executes
execlp("openin","openin","foo","pdopenr",(char *) 0). openin opens foo
for reading as fd 0 and then runs pdopenr, which gives a descriptor back
to the original process through fd passing. One feature of pdopen() is
that users can customize it easily: right now I can call

  pdopen("ftpread","wuarchive.wustl.edu:usenet/alt.sources/articles/4655",0)

and get a descriptor which reads from that file on wuarchive. Utilities
can use the syntax <&openin:foo. Voila: Uniform access to network files
and local files. No system changes required---the code for everything I
mentioned above already works on BSD, and I suppose that if I spend a
little more time on it, I could have pdopenr shuttle data through pipes
so that it doesn't need fd passing.

Why am I bringing up this invention on comp.std.unix? Because I'm trying
to make clear that it's just an *invention*, just like a version of
open() with the same features would be. There are many possible
solutions to the problem of accessing network files. super-open() would
have the advantage of working with programs which used open(). pdopen()
has the advantage of letting the user customize it easily. Neither is
appropriate for standardization, because no industry consensus exists.

Peter writes:
> I think Dan has a couple of basic problems in his argument here: first,
> looking at extensions to the file system as extensions to "open"; and
> second, missing the huge amount of code that comprises the "normal" UNIX
> environment that depends on a uniform name space.

I would like to correct three parts of Peter's summaries of my position.
First of all, Peter keeps bringing up syscalls other than open() which
manipulate filenames and which cannot be written in terms of file
descriptors. For example, creat(), link(), chmod(), and unlink() are
nonsensical without the concept of a filesystem. Peter then claims that
if there are mechanisms other than open() for creating file descriptors,
then the functions of creat(), link(), chmod(), and unlink() must all be
duplicated for those other mechanisms. But this is clearly nonsense: v7
had pipes, and didn't implement chmod() for pipes, and nobody has yet
complained at this omission. BSD had TCP/IP sockets, and didn't
implement chmod() for sockets, and nobody's complained about that
either. The protection mechanisms for the filesystem make sense for the
filesystem and *not* for network connections. So there is *no* need for
a version of chmod() (or any other filesystem-specific syscall) which
applies to network connections. BSD has a different, and much more
appropriate, protection mechanism for sockets; I'm glad that CSRG took
the time to work out good semantics for bind() rather than blindly
applying chmod() to some bastard network-filesystem creation.

Second, Peter says that I'm arguing against any form of uniform
namespace. Not at all. What I'm arguing against is the ``expectation''
of many POSIX members that POSIX will ``standardize'' an open() which
does something which has not won the market. If open() had worked for
network connections from the beginning, I wouldn't be complaining about
this issue in comp.std.unix.

Finally, Peter states

> Another problem with Dan's suggestions is that they reduce the name space
> available for normal files: a name space that's already hurt by the UNIX
> option syntax. If you start defining "3" to mean file descriptor 3,

but what I meant by this was that file descriptor numbers be used
*instead* of filenames, with the shell responsible for making this
transparent to the user. A utility which has already been mis-designed
to use filenames can stick to /dev/fd/3, which as I said before is a
rather good kludge to make such utilities behave.

---Dan


Volume-Number: Volume 26, Number 79

From [e-mail]  Tue Jan 14 15:01:02 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17068; Tue, 14 Jan 92 15:01:02 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25110; Tue, 14 Jan 92 15:00:14 -0500
Newsgroups: comp.std.unix
From: Paul Eggert <[e-mail]>
Subject: Re: Use of POSIX and X/Open Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Twin Sun, Inc
References: <[e-mail]> <[e-mail]>
Date: Sun, 12 Jan 1992 22:36:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

David Moore asks:
>Does anyone have any experience of applications development using POSIX
>interfaces only? Is it possible to write interactive applications for
>a commercial environment using only these interfaces?

I'd bet that not a single successful commercial application has ever been
written to Posix interfaces only.  Most installed Unix platforms do not conform
to Posix 1003.1, much less to the draft standards.  (1003.1 is the system API,
and is the only official standard so far.)  You can work around much of this
with configuration hacks but this means you're not using Posix interfaces only.

Furthermore, 1003.1 does not cover areas crucial to most application software.
Doug Gwyn pointed out the most glaring deficiency, namely user interfaces;
but there are several others.

Posix conformance is a worthy goal, but the best option for most real
applications is to strive for ``conforming using extensions'', instead of
``strictly conforming'' or ``conforming'' as Moore seems to be asking for.


Volume-Number: Volume 26, Number 81

From [e-mail]  Thu Jan 16 10:02:46 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09057; Thu, 16 Jan 92 10:02:46 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06308; Thu, 16 Jan 92 10:02:42 -0500
Xref: kithrup comp.std.unix:503 comp.std.internat:856
From: Roger Knobbe <[e-mail]>
Newsgroups: comp.std.unix,comp.std.internat
Subject: non-ASCII POSIX/XPG operating systems
Message-Id: <[e-mail]>
Organization: Locus Computing Corporation, Los Angeles, California
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 16 Jan 92 01:34:45 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Roger Knobbe)

Can anyone share experiences with running POSIX or XPG/3 conformance
suites on a non-ASCII machine?  I am researching a project in which
the native character set of the operating system will not be based
on ASCII.  I would like to find out if there are any systems in the
world already branded by XOPEN, or which have already passed NIST.

--
---
Roger Knobbe    \\ Locus Computing Corporation \\ Personal opinions only,
[e-mail] \\ 9800 La Cienega Blvd        \\ leave Locus out of it.
310/337-5267      \\ Inglewood, CA   90301-4440  \\  RAH JER   KUH NO BEE

[ Cross-posted to comp.std.internat, as Roger requested.  I think it's
  relevent to both, although the responses are more likely to be
  germaine to comp.std.unix -- mod ]

Volume-Number: Volume 26, Number 82

From [e-mail]  Thu Jan 16 10:02:53 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09094; Thu, 16 Jan 92 10:02:53 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06372; Thu, 16 Jan 92 10:02:50 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Peter da Silva <[e-mail]>
Organization: Xenix Support, FICC
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Jan 92 16:39:08 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> this is clearly nonsense: v7 had pipes, and didn't implement chmod()
> for pipes, and nobody has yet complained at this omission.

That's because this omission has been corrected with named pipes.

> BSD had TCP/IP sockets, and didn't
> implement chmod() for sockets, and nobody's complained about that
> either.

No, we've complained that sockets aren't in the file system's name space,
one of the reasons being that you can't access them through normal UNIX
system calls.

> Second, Peter says that I'm arguing against any form of uniform
> namespace. Not at all. What I'm arguing against is the ``expectation''
> of many POSIX members that POSIX will ``standardize'' an open() which
> does something which has not won the market.

Without implementing a uniform namespace, I can't see how POSIX could
possibly redefine open, by itself, to do this. Nor have I seen any
indication that any such standardization is being considered. There
has, however, been an ongoing discussion about moving more and more
facilities into the file system name space.

> I meant [...] that file descriptor numbers be used
> *instead* of filenames, with the shell responsible for making this
> transparent to the user.

You can't put file descriptor numbers in files.

You would also need to make the shell aware of which commands took FDs and
which took names (mv, for example), or have the user aware of which commands
took FDs and which took names (even worse... people are already ticked off
enough about the exceptions to a standard command syntax in UNIX).

> A utility which has already been mis-designed to use filenames

*mis*designed?

I think it's very useful that the same text strings can be used on the
command line and in data and configuration files.
--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 26, Number 83

From [e-mail]  Thu Jan 16 16:18:09 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02136; Thu, 16 Jan 92 16:18:09 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10116; Thu, 16 Jan 92 16:18:06 -0500
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 15 Jan 1992 16:42:50 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> Less
> powerful utilities don't need to open network connections any more than
> they need to open files; they can stick to file descriptors.

ln -s /dev/telnet/weather.com/540 ~/.plan # or whatever the name is
--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 26, Number 84

From [e-mail]  Sat Jan 18 18:22:43 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25945; Sat, 18 Jan 92 18:22:43 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24526; Sat, 18 Jan 92 18:22:40 -0500
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 18 Jan 1992 22:27:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Peter writes:
> Without implementing a uniform namespace, I can't see how POSIX could
> possibly redefine open, by itself, to do this. Nor have I seen any
> indication that any such standardization is being considered. There
> has, however, been an ongoing discussion about moving more and more
> facilities into the file system name space.

[sigh] I am arguing against ducks in all forms, whether or not you've
tied their bills so that they can't quack.

*WHY* is POSIX planning to move ``more and more facilities into the file
system name space''? *WHAT* gives POSIX committee members the delusion
that they can do a good job of this, given the history of incredibly
poor technical inventions made by standards committees throughout the
history of computing? *WHO* has the experience implementing and working
with these features in a UNIX environment? *WHERE* are the popular UNIX
systems which implement the uniform namespace features that POSIX wants
to standardize?

> You can't put file descriptor numbers in files.

foo >/dev/null 2>&1.

---Dan


Volume-Number: Volume 26, Number 85

From [e-mail]  Mon Jan 27 18:41:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26697; Mon, 27 Jan 92 18:41:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08298; Mon, 27 Jan 92 18:40:57 -0500
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Re: select() on pipe?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 27 Jan 1992 15:59:38 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> Peter writes:
> > Without implementing a uniform namespace, I can't see how POSIX could
> > possibly redefine open, by itself, to do this. Nor have I seen any
> > indication that any such standardization is being considered. There
> > has, however, been an ongoing discussion about moving more and more
> > facilities into the file system name space.

> [sigh] I am arguing against ducks in all forms, whether or not you've
> tied their bills so that they can't quack.

Personally, I don't care if they're ducks or chickens so long as I can
make a nice omolette with their eggs. Are you against eggs, or against
having POSIX raise the poultry? If you're against eggs, then let us into
the reason why instead of arguing about POSIX's farm policies or non-dairy
egg substitutes like "super open".

> *WHY* is POSIX planning to move ``more and more facilities into the file
> system name space''?

Well, this really does beg the question "*I* POSIX planning to move more
and more facilities into the fils system name space"? I see a lot of
discussion about moving things into the name space, but I don't see any
indication that POSIX is going to take an active role in this, other
than by documenting and standardising them when they get moved.

> *WHO* has the experience implementing and working
> with these features in a UNIX environment?

I've been using named pipes and Xenix semaphore- snad memory- special files
for some years now.

> *WHERE* are the popular UNIX
> systems which implement the uniform namespace features that POSIX wants
> to standardize?

Well, Xenix was the most popular UNIX system for quite a few years.

> > You can't put file descriptor numbers in files.

> foo >/dev/null 2>&1.

Care to explain this particular non-sequiter? How do you put a file descriptor
number in /etc/default/foo.cf?
--
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 26, Number 86

From [e-mail]  Mon Jan 27 18:51:26 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27786; Mon, 27 Jan 92 18:51:26 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11010; Mon, 27 Jan 92 18:51:24 -0500
Xref: kithrup comp.std.unix:509 comp.org.decus:442
Newsgroups: comp.std.unix,comp.org.decus
From: Tony Carrato <[e-mail]>
Subject: DECUS-US to drop OSF membership
Message-Id: <[e-mail]>
Followup-To: comp.org.decus
Originator: [e-mail]
Keywords: DECUS OSF
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Mile-High Information Services, Inc.
Date: Thu, 23 Jan 1992 23:39:01 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Tony Carrato)

The Open Software Foundation (OSF) is the body that produces the Motif
window manager and is in the process of producing the OSF/1 operating
system, which will be used as a basis for future Unix(tm)-like operating
systems by DEC, HP, IBM and a number of other vendors.  OSF also produces
a Distributed Communications Environment (DCE) and Distributed Management
Environment (DME).  These are software products for intersystem communications
and file system sharing (DCE) and security and system/network management (DME).
Finally, OSF produces the Application Neutral Distrribution Format technology,
a product aimed at allowing software to be developed on one architecture
and moved WITHOUT recompiling to another architecture.  (Yes, this
does work today, on about four or five platforms.)  (Note that the
term "product" could probably be argued.  I mean a package of
software and documentation, delivered to those OSF members who
choose to license it.)

The US Chapter of DECUS, the Digital Equipment Corporation Users' Society,
has been a member of OSF since its inception.  We have two dedicated
representatives who serve on the End User Steering Committee as well as
various technical Special Interest Groups.  This activity, to date,
has been under the DECUS standards committee.  In order to save money,
the standards committee's executive body has elected to drop DECUS'
membership in OSF.  (If you are a DECUS member or DEC user this means
YOUR representation.)  The reason is cost.  OSF dues are currently
$5,000 per year to a nonprofit organization.  (We're trying to get
those reduced.)  We also spend money travelling to meetings, though
a fair amount of those costs turn out to be borne by the rep's or
their companies instead of DECUS.

That brings us to THE QUESTION.......

Should DECUS-US drop out of OSF?  Do DECUS members want a voice in
what happens to Motif, OSF/1, etc. or should we expect the
various vendors we buy from, including others besides DEC, to
properly represent our interests as end users?  I've posted
this note to A LOT of groups.  How about directing follow ups
to comp.org.decus.  I'll track them and ship a response in to the
DECUS hierarchy.

Thanks,

Tony Carrato
DECUS OSF rep (for now)


----------------------------------------------------------------------------
Tony Carrato                Mile-High Information Services, Inc.
[e-mail]            [phone]
----------------------------------------------------------------------------


Volume-Number: Volume 26, Number 88

From [e-mail]  Mon Jan 27 18:51:25 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27784; Mon, 27 Jan 92 18:51:25 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10997; Mon, 27 Jan 92 18:51:22 -0500
Newsgroups: comp.std.unix
From: "John R. Levine" <[e-mail]>
Subject: Status of Posix lex and yacc
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Thu, 23 Jan 1992 04:00:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John R. Levine)

I am trying to figure out what to say about Posix in a book about lex and
yacc on which I am working.  I have the P1003.2/D11.2 draft from September.

Can someone say what the schedule is for newer drafts, and if it seems likely
that the discussions of lex and yacc or the extended regular expressions on
which lex depends are likely to change?  I note that the changes to lex and
yacc in 11.2 are almost entirely clarifications of funky cases.

Regards,
John Levine, [e-mail], {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 26, Number 87

From [e-mail]  Mon Jan 27 18:51:32 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27798; Mon, 27 Jan 92 18:51:32 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11033; Mon, 27 Jan 92 18:51:30 -0500
Newsgroups: comp.std.unix
From: Carl Symborski <[e-mail]>
Subject: help with POSIX.4a sigwait()
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: Steve Harpster <[e-mail]>
X-Submissions: [e-mail]
Organization: University of Maryland, College Park
Date: Sun, 26 Jan 1992 04:32:34 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Carl Symborski)

I am posting this for a friend.......

Carl

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

I'm looking at Draft 5 (Dec. 7, 1990) of POSIX.4a and I have a question
on sigwait() that hopefully someone out there in net-land can answer.

The first paragraph of the description (p. 112) says:

    "This function chooses a pending signal from set and atomically
     both clears and returns that signal number.  If no signal in
     set is pending at the time of the call, the thread shall be
     suspended until one or more becomes pending.  The signals defined
     by set shall be blocked when sigwait() returns.  The effect shall
     be as if sigwait() leaves an unspecified signal handler routine
     installed upon return."

What does it mean by "the signals defined by set shall be blocked when
sigwait() returns?"  Does sigwait() actually call sigprocmask() to block
the signal it just caught?  As an application writer, do I then have to
call sigprocmask() afterwards to unblock the signal?

Consider the following:

    (void) sigemptyset(&set);
    (void) sigaddset(&set, SIGALRM);
    (void) sigwait(&set);
        .
        .
        .
    (void) sigwait(&set);

Because I forgot to unblock SIGALRM, my thread is now deadlocked, right?

Of course I'm assuming that sigwait() will *not* choose a pending signal
that's also blocked.  Section 8.4.6.2 on synchronous signal delivery states
that applications may call sigprocmask() to examine or change (or both)
the calling thread's signal mask.  If sigwait() chose blocked and unblocked
signals, what would be the point of blocking signals while in synchronous
delivery mode?

Can someone please explain the intent here?  Many thanks....

--
Stephen Harpster
Hughes Network Systems
[e-mail]


Volume-Number: Volume 26, Number 89

From [e-mail]  Mon Jan 27 18:51:38 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27809; Mon, 27 Jan 92 18:51:38 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11053; Mon, 27 Jan 92 18:51:35 -0500
Newsgroups: comp.std.unix
From: Jeffrey Kegler <[e-mail]>
Subject: On-line drafts
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Reply-To: Jeffrey Kegler <[e-mail]>
X-Submissions: [e-mail]
Organization: Algorists, Inc.
Date: Sun, 26 Jan 1992 09:06:32 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeffrey Kegler)

At USENIX Thursday I attended Jeffrey Haemer's Invited Talk (very
informative!).  He suggested that an issue which had concerned me but
which I had not though terribly relevant to this group was indeed very
relevant.  (That does not make him responsible for what I am about to
say.)

At present there is an "experiment" with on-line drafts.  This is
overdue, and should be more than an experiment with a few drafts.

I subscribe to the drafts-only standard selection.  The order form
makes it look, and it has been suggested to me, that this is made to
order for folks like me.  In fact, it's a damned inconvenience and
causes heavy and unnecessary bleeding in both time and cash.  I spend
about $250 a quarter.  The company pays for it, but I am the company,
and it is a desperate enterprise, usually barely ahead of my bar
bills.

What I get is hard to work with.  "Drafts only" in practice means that
each committee marks each monthly mailing as to whether it *contains*
a draft.  If so, I get the whole committee's mailing, including
non-draft material.  Worse, whoever makes the draft/non-draft call
often interprets the meaning of "draft" very lightly.  A few pages
from another committee's draft, with hand-written notes, has been
called a draft and I have to pay for it, and many pages of clearly
non-draft materials, at a per-page rate.

Working with all this hardcopy is time-consuming.  My main purpose is
to be able to get from my shelves each committee's latest draft.  Each
month I have to open each committee's work, figure out what in it is a
draft (usually on a few I give up--nothing in it looks like draft even
by the weak criteria suggested above), and put it in the right
notebook.  Each committee's work is shrink-wrapped, but what material
came from what committee is also non-obvious.  The committee's ID is
often on much of the stuff (not always, though!), but many committees
look extensively at, and include extensive excerpts from, the work of
others, so which committee sent what is often undecidable.  This all
takes several hours a month I could be devoting to actually reviewing
the standards.

Clearly, in order to get all this material reviewed, as many people
should be enabled to get involved as possible.  I doubt that many
others in my situation are willing to throw all this time and money at
POSIX--and all this time is expended before I actually get to read a
single line!  The earlier lack of electronic copies, and the present
"experiment" of having only a few on-line makes reviewing draft
standards an impossibility for most.

Jeff Haemer in his talk pointed out that the volume of the material
soon to go into the review process is unprecedented, and the present
system (organized to handle electrical standards whose median size was
about 25 pages) will, at best, be strained.

I think I am not going too far in saying that, even with thorough
review, the likelihood of issuing over the next few years, bad
standards, is high.  The best single way of improving the odds, is
widening the review process.  Electronic access is not just a nice
thing to keep Jeffrey Kegler from being left out, it is a necessity to
prevent disaster.

I am among those who finds the rush to standardization gratifying.
But we all must acknowledge each new standard, "voluntary" or not, is
a chamber in a revolver pointed at our head.  The concern that didn't
make its way to the committee today may be your own tomorrow.  When
your customer demands POSIX, and the standard committee fell into the
hands of a clique (perhaps composed of sincere people who did not
realize they only represented part of the constituency), you can be
badly hurt.  A bullet or two is likely to wind up in the gun anyway,
but we need to make every effort to keep all those chambers empty.

Early I had thought that the IEEE does this as a way of raising
revenue.  At USENIX just ended, Jeff Haemer and others told me that is
not the case.  There is no intent to generate cash flow from drafts,
except that necessary to cover the burden of copying, collating and
mailing lots of hardcopy.  (Important note: here I am speaking of
unapproved drafts only--charging for copies of approved standards is
another issue, which I am not addressing in this post).

Off The HardCopy Monopoly!  Drafts to the People!  Bits, not bulk
mail!



--

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail] or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087



Volume-Number: Volume 26, Number 90

From [e-mail]  Tue Jan 28 20:23:12 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19852; Tue, 28 Jan 92 20:23:12 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04003; Tue, 28 Jan 92 20:22:14 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: On-line drafts
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Tue, 28 Jan 1992 23:47:14 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (Jeffrey Kegler)
>... the likelihood of issuing over the next few years, bad
>standards, is high.  The best single way of improving the odds, is
>widening the review process...

I'd like to strongly support Jeffrey's comments.  I simply do not have time
to wade through all the paper; my involvement with 1003.2 review, in
particular, depends on either having someone else do that for me, or
having online access to pieces of drafts.  Being able to FTP relevant
parts of 11.2 made it an order of magnitude easier to properly review
the regular-expression stuff and the awk definition (which meant picking
up various other pieces for context, e.g. the character-set stuff)...
and I found half a dozen significant problems with each as a result.

In case anyone is wondering about details, I make use of both the plain
ASCII version and the PostScript version, the former for grepping when
looking for something specific, and the latter for reading as a whole.
If I had to make a choice between them, the PostScript is marginally
preferable.

I don't object to buying a copy of the final standard, even though I
tend to grit my teeth at the cost, but online access is just the only
way to review parts of drafts properly under time constraints.
--
"Breakthrough ideas are not             | Henry Spencer @ U of Toronto Zoology
from teams."  -- Hans von Ohain         |  [e-mail]  utzoo!henry

Volume-Number: Volume 26, Number 91

From [e-mail]  Thu Jan 30 17:43:22 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07035; Thu, 30 Jan 92 17:43:22 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17184; Thu, 30 Jan 92 17:43:19 -0500
Xref: kithrup comp.std.unix:513 comp.sources.wanted:5032
Newsgroups: comp.std.unix,comp.sources.wanted
From: randy kunkee <[e-mail]>
Subject: Question about PAX and USTAR format
Message-Id: <[e-mail]>
Followup-To: comp.sources.wanted
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Unix/Xenix Support Group
Date: Thu, 30 Jan 1992 17:56:28 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (randy kunkee)

I have version 1.2 of "PAX - Portable Archive Interchange" written
by Mark Colburn.  First, many thanks to Mark, and to Larry Jones for
his unofficial patches to PAX, and thanks to USENIX for sponsoring
its development.  This is a very useful utility and I've been using
it in some of our systems as a backup utility.

Unfortunately, the version of PAX I have has trouble when restoring linked
files.  This is because the routines for managing links depend on knowing
a file's device and inode number.  This information is available in cpio
format, but not in tar format.  PAX blithely tries to link everything that
has a link together, since the device and inode numbers passed to the
link routines are always zero.

Does anybody have code that fixes PAX's ability to restore links from
(US)TAR format?

[ Note followup, please -- mod ]

Volume-Number: Volume 26, Number 92

From [e-mail]  Mon Feb  3 15:03:24 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17971; Mon, 3 Feb 92 15:03:24 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20159; Mon, 3 Feb 92 15:03:15 -0500
Newsgroups: comp.std.unix
From: Andrew Hume <[e-mail]>
Subject: Re: On-line drafts
Message-Id: <[e-mail]>
Summary: comments are invited on online drafts
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
References: <[e-mail]> <[e-mail]>
Date: Sat, 1 Feb 1992 06:29:56 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

    Thanks to spencer and kegler for their comments on
the online drafts that are available. I would invite folks
to comment on this, either in this forum or to me, and with
either positive or negative feedback. I provide the service
for the POSIX stuff and such feedback is valuable to me but
I have an ulterior motive. At some point, IEEE will want to
know how the experiment has gone. I can provide statistics
(like 7000 requests in the first two months) but i think
testimonials are just as illuminating. And of course, I am
interested in knowing about problems.


        Andrew Hume
        [e-mail]


Volume-Number: Volume 26, Number 93

From [e-mail]  Wed Feb  5 19:53:05 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12336; Wed, 5 Feb 92 19:53:05 -0500
Received: from kithrup.COM by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19174; Wed, 5 Feb 92 19:52:54 -0500
Newsgroups: comp.std.unix
From: Brian May <[e-mail]>
Subject: Query on IEEE P1003.17: X.500 API
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: CSIRO DIT (Melb.)
Date: Tue, 4 Feb 1992 23:54:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Brian May)

I am looking for information regarding the above Posix API for X.500.

Any pointers to people/groups involved with the formulation of, or on the
status of the definiton would be greatly appreciated.

forwards thanks,

brian may
--
|  Brian May, DIT, CSIRO,  |       Open Communications Project        |
|723 Swanston st, Carlton, | TEL [phone] -- FAX [phone] |
|   VIC 3053, Australia.   |     email [e-mail]     |


Volume-Number: Volume 26, Number 94

From [e-mail]  Fri Feb  7 16:59:54 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03123; Fri, 7 Feb 92 16:59:54 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16353; Fri, 7 Feb 92 16:59:44 -0500
Newsgroups: comp.std.unix
From: Jason Zions <[e-mail]>
Subject: Re: Query on IEEE P1003.17: X.500 API
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard,     Colorado Networks Division
Date: Fri, 7 Feb 1992 17:47:33 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

   I am looking for information regarding the above Posix API for X.500.

   Any pointers to people/groups involved with the formulation of, or on the
   status of the definiton would be greatly appreciated.

The current chairman of 1003.17 is:

Rob Spade
3702 East Salinas Street
Ahwatukee, AZ  85044
[phone]

The latest draft of 1003.17, and of most IEEE-CS standards, can be obtained
by contacting:

Lisa Granoien
Assistant Director for Standards/TAB
IEEE Computer Society
1730 Massachusettes Ave NW
Washington DC  20036-1903
[phone]
Fax: [phone]

Current plan appears to be to enter ballot around June of this year; contact
the chair for additional information.

All of this information is available on a quarterly basis in the IEEE-CS
Standards Status Bulletin, produced by the IEEE-CS; contact IEEE-CS at the
above address for subscription information.
--
Jason Zions, Chair IEEE P1003.8 Transparent File Access

I do not speak for 1003.8, TCOS, IEEE-CS, IEEE, or my employer.


Volume-Number: Volume 26, Number 95

From [e-mail]  Wed Feb 12 17:27:53 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24788; Wed, 12 Feb 92 17:27:53 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16208; Wed, 12 Feb 92 17:27:47 -0500
Newsgroups: comp.std.unix
From: Jean-Ren BOUVIER <[e-mail]>
Subject: posix.3 and .4 wanted
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Hewlett-Packard Grenoble
Date: Mon, 10 Feb 1992 14:56:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jean-Ren BOUVIER)

I'm looking for an electronic version of posix 1003.3 and 1003.4.  Could
someone  point me to a server  accessible  via email (I have no  general
access to ftp) ?

[e-mail]

[ I am posting this because it is fairly typical of some messages I've
  been getting.  I have been told, and I'll consider it "official" for
  now, that there are NO on-line drafts available to the general pub-
  lic; there are some available to people who have already paid for the
  printed versions, and need the electronic form to sift through it
  more easily.  This is the situation as I understand it, although I
  am welcome to corrections from people who know.  In the meantime, as
  usual, the information on where to get POSIX drafts and information
  is available on ftp.uu.net via anonymous ftp, in
  usenet/comp.std/unix/Obtaining  -- mod ]

Volume-Number: Volume 26, Number 97

From [e-mail]  Wed Feb 12 17:28:50 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24812; Wed, 12 Feb 92 17:28:50 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16367; Wed, 12 Feb 92 17:28:43 -0500
Newsgroups: comp.std.unix
From: Chesley Reyburn <[e-mail]>
Subject: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Summary: point of information
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Computervision R&D, Beaverton OR
Date: Tue, 11 Feb 1992 21:53:54 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chesley Reyburn)

Hello POSIX fans!

I have a very treasured application that I am porting to POSIX and I
have a question about whether POSIX will support it or not.

This thing does dynamic, on-the-fly, loading of user supplied sourca
modules during run-time.  Is this behaviour that POSIX will support?
If so which POSIX standard will specify it?  If not, why are you people
wasting my time :->  ?

Thanks


Chesley Reyburn                       [e-mail]
ECAE Software, Prime Computer, Inc.   Phone: [phone]
14952 NW Greenbrier Parkway           Beaverton, OR 97006-5733, USA


Volume-Number: Volume 26, Number 98

From [e-mail]  Wed Feb 12 17:41:56 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26019; Wed, 12 Feb 92 17:41:56 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20858; Wed, 12 Feb 92 17:41:47 -0500
Newsgroups: comp.std.unix
From: Dominic Dunlop <[e-mail]>
Subject: Re: On-line drafts
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>
Date: Tue, 11 Feb 1992 11:09:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]
[e-mail] (Jeffrey Kegler) writes about the
deficiencies and inefficiencies he perceives in the current scheme for
distributing POSIX working group papers and draft standards in hard-copy
form.

I wholly agree.  I still have a large pile of unfiled stuff myself.

Clearly, anybody who reads this list is likely to consider, like
Jeffrey, that
> Electronic access is not just a nice
> thing to keep Jeffrey Kegler from being left out, it is a necessity to
> prevent disaster.

Given that we all agree, the question then becomes ``So who pays?''
Jeffery estimates his costs at $1,000 per year to receive rather more
documents than he actually needs in a form that he finds difficult to
handle.  How much would people be willing to stump up to get access to
the documents that they actually want, in a form that they can handle,
and in a timely manner?  If this number were on the order of (although
hopefully less than) $1,000 per year, a NON-PUBLIC ftp archive could be
set up to provide the service, and would likely be adequately funded.
Such a service would require seed capital in order to get up and
running.  Anybody feel like being a sugar daddy with a loan or
contribution?  (Some user group, professional association or industry
body, for example?)

The current pilot scheme for those specifically involved with the
development of the standards is of course very welcome, but I fear it
would be naive to expect any one organization to run a
publicly-accessible archive far ALL POSIX working materials free for
all out of the goodness of its corporate heart: there's just too high a
volume of material.  Similarly, it is naive to expect paying customers
to stump up for a public service to which subscribers would have no
better access than non-subscribers.  That's why I suggest the concept
-- anathema to many users of the net -- of a non-public archive.  The
downside is that such archives take more administering than public
ones.  (I point out in passing that commercial services like Compu$erve
are only too pleased to supply access to such ``value added services'',
and can do the billing for you.)

Any archive would need submission guidelines as regards the format in
which data may be supplied.  Much material is currently handwritten, or
produced on any one of a hundred word-processors, desk-top publishing
systems, or presentation packages.  That would not be acceptable.
It Would Be Nice if the list of acceptable formats included

  -- ASCII
  -- troff -mm with POSIX macros
  -- ISO 8859-1
  -- group 3 fax (which would allow images of files in otherwise
     unacceptable formats to be held.)
  -- PostScript

(Given my current job, I suppose I should propose an all-encompassing
SGML-based format.  No.  I won't do that.)  Those who submit material
to the archive should probably be limited to working group chairs,
secretaries and co-chairs.  More costs in policing...

And it must be understood that the archive would not supplant the
current paper-based distribution system.  It would have to run in
parallel.

What does anybody else think?  (Just hold on while I get behind these
sandbags.)
--
Dominic Dunlop

Volume-Number: Volume 26, Number 96

From [e-mail]  Sun Feb 16 03:09:38 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15329; Sun, 16 Feb 92 03:09:38 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27122; Sun, 16 Feb 92 03:09:36 -0500
Newsgroups: comp.std.unix
From: Huy Nguyen <[e-mail]>
Subject: Posix.4, real-time signal extension
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
Reply-To: Huy Nguyen <[e-mail]>
X-Submissions: [e-mail]
Organization: Silicon Graphics, Research & Development
Date: Sun, 16 Feb 1992 01:00:17 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Huy Nguyen)

In Posix.4 draft 10, section 7 on real-time signals extension, page
119, the draft mentions that the range SIGRTMIN through SIGRTMAX
inclusive shall include at least {RTSIG_MAX} signal numbers. A
conforming implementation shall support a value for {RTSIG_MAX} of at
least {_POSIX_RTSIG_MAX}.

However, I couldn't find where _POSIX_RTSIG_MAX is defined? Is this an
omission or it is up to the implementation to specify that limit in
limits.h.  Also, there is no mention of the signal names of the signals
that fall between {SIGRTMIN, SIGRTMAX}. For portability, one would
assume that the draft will specify the convention on these signal
names. Can someone help me out on this?


Thanks

Volume-Number: Volume 26, Number 99

From [e-mail]  Mon Feb 17 18:04:36 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17929; Mon, 17 Feb 92 18:04:36 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17881; Mon, 17 Feb 92 18:04:33 -0500
Newsgroups: comp.std.unix
From: "Scott E. Preece" <[e-mail]>
Subject: Re: Posix.4, real-time signal extension
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Motorola MCD, Urbana Design Center
References: <[e-mail]>
Date: Mon, 17 Feb 1992 15:56:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scott E. Preece)

In article <[e-mail]> [e-mail] (Huy Nguyen) writes:

>In Posix.4 draft 10, section 7 on real-time signals extension, page
>119, the draft mentions that the range SIGRTMIN through SIGRTMAX
>inclusive shall include at least {RTSIG_MAX} signal numbers. A
>conforming implementation shall support a value for {RTSIG_MAX} of at
>least {_POSIX_RTSIG_MAX}.
>However, I couldn't find where _POSIX_RTSIG_MAX is defined?

I can't speak to draft 10, but in Draft 11 the definition is in section
2.7.1 on page 23 -- it requires the range to be at least 8.

I believe the idea of the range of values is that they are available for
the application writer to use to define application-specific signals.
The numbering implies priority ordering, so the application has a lot of
freedom to do real-time-ish things with the signals in the RT range.

I think the idea is you do something like:
    #define SIGCOLLISION SIGRTMIN
    #define SIGPROXIMITY SIGRTMIN+1
    ...

--
scott preece
motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]


Volume-Number: Volume 26, Number 100

From [e-mail]  Mon Feb 17 18:04:39 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17935; Mon, 17 Feb 92 18:04:39 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17888; Mon, 17 Feb 92 18:04:36 -0500
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: On-line drafts
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]>
Date: Mon, 17 Feb 1992 18:28:55 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Dominic Dunlop) writes:
>... How much would people be willing to stump up to get access to
>the documents that they actually want, in a form that they can handle,
>and in a timely manner?  If this number were on the order of (although
>hopefully less than) $1,000 per year [it could be done commercially].

Such prices would be utterly prohibitive for the sorts of use I have had
for online 1003.2-draft access.  For me, the whole point of online access
is hassle-free access to selected* small pieces of the draft.  Neither I
nor my employer has any budget for this whatsoever.  My attention to
regular expressions and awk -- small areas, but ones where I think I have
made significant contributions to the quality of the final result -- is
possible only because no significant cash expense is incurred.

(*  Note that when I say "selected", I do not mean "pre-selected".
Reviewing -- or implementing -- 1003.2 regular expressions properly
requires careful attention to several sections that superficially have
nothing to do with regular expressions.  One of the most valuable
aspects of online access was being able to chase down cross-references
quickly.)

I suggest that the greatest value of online access is not as a more
convenient way to serve the same population, but as a way to get more
people involved and thus produce higher-quality standards.  This will
not happen if costs are such that management approval and explicit
budgeting are necessary.  Online access can be a way to distribute
the same old stuff to the same old people at the same old cost-recovery
prices, or it can be an *investment* in better standards through wider
and easier participation.
--
SVR4:  proving that quantity is         | Henry Spencer @ U of Toronto Zoology
not a substitute for quality.           |  [e-mail]  utzoo!henry


Volume-Number: Volume 26, Number 101

From [e-mail]  Tue Feb 18 15:53:47 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03650; Tue, 18 Feb 92 15:53:47 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11797; Tue, 18 Feb 92 15:53:45 -0500
Newsgroups: comp.std.unix
From: Donald Lewine <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Data General Corporation
References: <[e-mail]> <[e-mail]>
Date: Tue, 18 Feb 1992 14:10:18 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]>, [e-mail] (Chesley Reyburn) writes:
> This thing does dynamic, on-the-fly, loading of user supplied sourca
> modules during run-time.  Is this behaviour that POSIX will support?
> If so which POSIX standard will specify it?  If not, why are you people
> wasting my time :->  ?

POSIX does not specify dynamic linking and is not likely to do so.
POSIX covers the source level view of the computer.  There is no
need (as far as POSIX is concerned) to ever compile or link anything.

One could implement POSIX using a very fast and very smart cockroach.
As long as the source program produces the right output the cockroach
is POSIX conforming.

Clearly, POSIX allows for systems which do use compilers and linkers,
but it does not require that they work in any particular way.

--------------------------------------------------------------------
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 26, Number 102

From [e-mail]  Tue Feb 18 19:38:57 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07444; Tue, 18 Feb 92 19:38:57 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04469; Tue, 18 Feb 92 19:38:54 -0500
Newsgroups: comp.std.unix
From: Stephen Walli <[e-mail]>
Subject: OSF/Motif PAR Resurrected
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 18 Feb 1992 03:19:45 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

Hi,

The following notice came through a friend.
Despite a bit of marketing warm fuzzies, and a few partial facts,
this seemed like a place to post it so the largest group of people
might be aware of the upcoming meeting.

cheers,
stephe
------------------------------------------------------------------------------


OSF/Motif Standard Update and Meeting Notice


This letter was recently sent to OSF members supporting
the OSF/Motif standard effort.


Dear OSF Member,

I would like to express OSF's appreciation for the support you've shown
for OSF/Motif and in particular, for your support of the evolution of
OSF/Motif as a formal standard.  I also would like to bring you up to
date on events this past year and to encourage you to send a
representative to the first meeting of the Modular Toolkit Environment
(MTE) work group otherwise known as the Motif standard effort.

Almost a year ago, OSF with the backing of dozens of supporters
representing a broad cross-section of the industry, proposed to the
IEEE that a standard be developed based on OSF/Motif.  This standard
would move the evolution of the OSF specification - the Applications
Environment Specification - into a wider arena and would also place the
specification into a consensus process. It is the logical fruition of
OSF's efforts that the base specification, produced cooperatively under
our vendor neutral charter, be presented to the appropriate standards
body for its future evolution.

The committee petitioned--the Technical Committee on Operating Systems
and Applications Environments (TCOS) of the Computer Society--debated
the proposal during two meetings, over a period of six months.  The
reason that this debate occurred and that the proposal was not
initially approved was that at the last minute, a proposal based on
OPEN LOOK was submitted by representatives from Sun Microsystems and
UNIX System Laboratories (USL).  In spite of widespread support for the
OSF/Motif proposal, the committee took both proposals under
consideration.  However, many of the TCOS members could not support the
notion of two standards in a similar problem space.

After further consultation with OSF members,  OSF decided to move the
proposed work forward.  Thus, OSF proposed the work group to the
Computer Society's board directly, as is allowed by IEEE rules,
bypassing the committee which found two standards in one problem space
unacceptable.  At the higher level committee, the problem of two
standards was dismissed and the Computer Society agreed to sponsor in
principle both the OSF/Motif proposal and the OPEN LOOK proposal.
Final approval is anticipated in March.

With this go ahead, we have scheduled the first meeting of the work
group to develop the standard for OSF/Motif with a target completion
date of year end 1992.  At the upcoming meeting, the work group will
elect officers and evaluate the plan to produce the standard.  This
open group seeks to include all appropriate constituencies and to be
well balanced among interested users, system vendors and independent
software vendors.  The first meeting will be held at OSF in Cambridge,
February 24-25.

A copy of the proposed work for the IEEE, a draft agenda, and a general
invitation letter is available.  To receive a copy, contact Lorraine
Burrage at phone:  [phone] or by email at [e-mail].  Please
forward these documents to the appropriate individual(s) in your
organization. Once again, if you have an interest in seeing OSF/Motif
progressed as a standard and wish to support the standardization
effort, we look forward to seeing a representative of your company at
the meeting in February.  If no one from your company can attend,
written comments would be appreciated.  The direction the standard
takes as well as the changes planned to the OSF/Motif interfaces and
style will be determined by this work group.

Once again, thank you for your support.  That support and that support
alone makes this forward motion in the industry possible.


John S. Morris Director, Technical Liaisons



Volume-Number: Volume 26, Number 103

From [e-mail]  Tue Feb 18 19:39:01 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07463; Tue, 18 Feb 92 19:39:01 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04483; Tue, 18 Feb 92 19:38:59 -0500
Newsgroups: comp.std.unix
From: Donald Lewine <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Data General Corporation
References: <[e-mail]> <[e-mail]>,
Date: Tue, 18 Feb 1992 14:10:18 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]>, [e-mail] (Chesley Reyburn) writes:
> I have a very treasured application that I am porting to POSIX and I
> have a question about whether POSIX will support it or not.
>
> This thing does dynamic, on-the-fly, loading of user supplied sourca
> modules during run-time.  Is this behaviour that POSIX will support?
> If so which POSIX standard will specify it?  If not, why are you people
> wasting my time :->  ?

POSIX does not specify dynamic linking and is not likely to do so.
POSIX covers the source level view of the computer.  There is no
need (as far as POSIX is concerned) to ever compile or link anything.

One could implement POSIX using a very fast and very smart cockroach.
As long as the source program produces the right output the cockroach
is POSIX conforming.

Clearly, POSIX allows for systems which do use compilers and linkers,
but it does not require that they work in any particular way.

--------------------------------------------------------------------
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 26, Number 104

From [e-mail]  Wed Feb 19 15:37:27 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09788; Wed, 19 Feb 92 15:37:27 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13447; Wed, 19 Feb 92 15:37:24 -0500
Newsgroups: comp.std.unix
From: Barry Margolin <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <[e-mail]> <[e-mail]>
Date: Wed, 19 Feb 1992 05:57:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] writes:
>POSIX does not specify dynamic linking and is not likely to do so.
>POSIX covers the source level view of the computer.  There is no
>need (as far as POSIX is concerned) to ever compile or link anything.

What about the kind of stuff that one needs dlopen() for, i.e. where a
runtime-specified module must be linked in?  That's a source-level view.

--
Barry Margolin
System Manager, Thinking Machines Corp.

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

Volume-Number: Volume 26, Number 105

From [e-mail]  Wed Feb 19 15:38:29 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09862; Wed, 19 Feb 92 15:38:29 -0500
Received: from kithrup.COM by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13457; Wed, 19 Feb 92 15:37:26 -0500
Newsgroups: comp.std.unix
From: Guido van Rossum <[e-mail]>
Subject: Re: POSIX question: dynamic linking
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX dynamic linking
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Date: Wed, 19 Feb 1992 11:53:53 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

[e-mail] (Donald Lewine) writes:
>POSIX does not specify dynamic linking and is not likely to do so.
>POSIX covers the source level view of the computer.  There is no
>need (as far as POSIX is concerned) to ever compile or link anything.
>
>One could implement POSIX using a very fast and very smart cockroach.
>As long as the source program produces the right output the cockroach
>is POSIX conforming.

This is the standard argument from language specification people to
ignore certain issues of the real world.  Remember what it did to
Pascal, which tried to ignore the issue of separate compilation.  Come
on folks, the C standard requires binary arithmetic!
That's the way to go!

Thes standards (especially POSIX!) are for users, not for
mathematiciancs.  As soon as good implementations of dynamic loading
become common (and I suspect this will be very soon) a cry for
standardization will result.

I have already been forced to design a lowest-common-denominator
dynamic loading interface and to provide two different implementations
for it, in order to support extensibility for a very portable language
implementation I'm maintaining, and I hope I won't have to write too
many other ports.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"The plumage don't enter into it.  He's stone dead!"


Volume-Number: Volume 26, Number 106