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

Internet Message Format | 1988-04-18 | 212KB

From uucp  Sun Jan 24 11:03:40 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA06344; Sun, 24 Jan 88 11:03:40 EST
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 13
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 22 Jan 88 04:42:19 GMT
Apparently-To: std-unix-list
Status: RO

This is the first article in Volume 13 of comp.std.unix.

The USENET newsgroup comp.std.unix is also known as the ARPA Internet
mailing list [e-mail].  It is for discussions of UNIX
standards, particularly of IEEE 1003, or POSIX.  The moderator is
John S. Quarterman, who is also the institutional representative of
the USENIX Association to the IEEE P1003 Portable Operating System
Interface for Computer Environments Committee (commonly known as
the UNIX Standards Committee).

Submissions-To:    uunet!std-unix        or [e-mail]
Comments-To: uunet!std-unix-request    or [e-mail]
The former addresses through sally.utexas.edu or ut-sally still work.
Postings from the moderator may also originate from longway.tic.com.

Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

Archives may be found on uunet.uu.net.  The current volume may
be retrieved by anonymous ftp (login anonymous, password guest)
over the ARPA Internet as
    ~ftp/comp.std.unix/archive
or
    ~ftp/comp.std.unix/volume.13
The previous volume may be retrieved as
    ~ftp/comp.std.unix/volume.12
For hosts with direct UUCP connections to the uunet machine,
UUCP transfer should work with, for example,
    uucp uunet!comp.std.unix/archive archive

Volumes 1-10 are filed under the former newsgroup name, mod.std.unix,
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc., through
~ftp/pub/mod.std.unix.v10.  Volume 3 contains the AT&T public domain
getopt(3).  Volume 10 is a special index volume that catalogs Volumes 1-9.

These volumes are strictly for administrative convenience.
Paper copies of them get delivered to the P1003 committee chair
from time to time and several members of the committee follow
the newsgroup on-line.

Finally, remember that any remarks by any committee member (especially
including me) in this newsgroup do not represent any position (including
any draft, proposed or actual, of a standard) of the committee as a
whole or of any subcommittee unless explicitly stated otherwise
in such remarks.

UNIX is a Registered Trademark of AT&T.
POSIX is a Trademark of IEEE.
IEEE is a Trademark of the Institute of Electrical and Electronics
    Engineers, Inc.

Volume-Number: Volume 13, Number 1

From uucp  Sun Jan 24 12:18:15 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09415; Sun, 24 Jan 88 12:18:15 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (1 0f 4): Overview
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 24 Jan 88 17:15:49 GMT
Apparently-To: std-unix-list
Status: O


                      Standards Update
        An update on UNIX and C Standards Activities

                      January 21, 1988

             Written for the USENIX Association
              by Shane P. McCarron, NAPS Inc.

[This report was written at the request of the Board of
Directors of the USENIX Association.  In the interests of
reducing article sizes and making followups easier to
manage, I am posting it in four parts, divided according to
the following topics:

     Overview
     X3J11 and the X3.159 C Programming Language Standard
     NBS FIPS
     IEEE P1003 Subcommittees

-mod]

The Standards community isn't necessarily a closed entity,
but it is one that is hard to look into.  There are so many
different activities going on all over the place that it is
difficult for the most people to get involved.  I suppose
this is as it should be, since if everyone were involved,
nothing would ever get accomplished.  However, it is always
good to know what is going on at a macro level, even if the
details pass you by.

That is where this report comes in - I am going to try and
summarize what has transpired in the Unix and C standards
areas during the previous three months.  As anyone who has
been involved in a standards committee can tell you, not a
lot will happen in a quarter in any one committee, but over
several committees the cumulative effect can be daunting.

Before I start summarizing what went on in the last quarter
on 1987, I should define the scope of this report.  I am not
going to try to touch on all of the technical discussions
that go on.  These are often boring, and if you have that
level of interest, you should really be on the mailing list
for the group in question.  Instead, I am going to give an
overview of some of the key issues that were raised and the
important milestones that were reached or passed.

In addition to the activity at the December meetings of
P1003, a few other things happened that are worth noting:

   - P1003.1 Final Ballot

Overview, January 21, 1988      Shane P. McCarron, NAPS Inc.


Standards Update           - 2 -          USENIX Association

     On November 15th the P1003.1 document went out for its
     full use ballot.  The balloting period was 30 days, and
     closed around December 15th.  When ballot resolution is
     completed, the first full use standard from a 1003
     group will have been ratified.  This should be around
     March, 1988.

   - New P1003 Working Groups

     There are three new working groups under the P1003
     committee (.0, .5, and .6).  Since I haven't talked
     about all of these before, here is a list of all of the
     POSIX working groups:

               1003.0 - POSIX Guide
               1003.1 - Systems Interface
               1003.2 - Shell and Tools Interface
               1003.3 - Verification and Testing
               1003.4 - Real Time
               1003.5 - Ada Binding for POSIX
               1003.6 - Security

   - IEEE Standards Board

     At the December meeting of the IEEE Standards Board,
     the Board approved the IEEE Technical Advisory Group
     Procedures document.  This was a major event in that it
     allowed the first meeting of the United States TAG on
     POSIX to take place "in wedlock".

   - US Technical Advisory Group on POSIX

     The first meeting of the US TAG on POSIX was held in
     conjunction with the P1003 meetings in December.  A TAG
     is a group that exists in each International Standards
     Organization (OSI) member country that is interested in
     a particular ISO working group (in this case, WG15 of
     Suncommittee 22).  The TAG recommends to the ISO
     standards body for that topic in that country what the
     countries' position should be on the issue.  In this
     case the standards body is the IEEE, and the issue is
     POSIX.  In a future report, I hope to spend more time
     talking about what it means to be in the International
     Standards Organization, and how it effects POSIX.

     Since it was the first meeting, the members present
     elected a chair and secretary, and learned about what
     it means to be a TAG.  In addition to this, the TAG
     established what the US position on POSIX should be.
     Basically this boils down to "The US recommends that

Overview, January 21, 1988      Shane P. McCarron, NAPS Inc.


Standards Update           - 3 -          USENIX Association

     POSIX be accepted as a Draft Proposed Standard, but any
     changes made to the standard by IEEE P1003.1 should be
     incorporated into the ISO document."  It would be very
     bad form not to recommend our own standard :-)

Overview, January 21, 1988      Shane P. McCarron, NAPS Inc.


Volume-Number: Volume 13, Number 2

From uucp  Sun Jan 24 12:19:58 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09717; Sun, 24 Jan 88 12:19:58 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (2 of 4): C Language
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 24 Jan 88 17:18:56 GMT
Apparently-To: std-unix-list
Status: O


                      Standards Update
        An update on UNIX and C Standards Activities

                      January 21, 1988

             Written for the USENIX Association
              by Shane P. McCarron, NAPS Inc.

   - C Language Standard

     In addition to the P1003 standards activities, the work
     of the X3J11 standards committee holds particular
     interest for people in the un*x community.  This is the
     group that is defining the ANSI X3.159 C Language
     Standard.  They have been working on this for quite a
     while now, and are very close to resolution.  They went
     into their first public review period last spring, and
     have just recently finished responding to all of the
     comments that were submitted at that time.

     Based on information I have about the December meeting
     of X3J11, here is what is happening in the future:

        - Around January 8th, 1988 the second public review
          draft will be completed.

        - Soon after that, the second (2 month) public
          review period will begin.  As with last time, the
          standard will be available to the public through
          Global Press in Washington, DC.

        - This public review will close in time for the
          comments to get out to the committee members
          before the April meeting.

        - At that meeting, the committee will break down
          into subgroups and review the comments.  There
          will be great resistance to making any substantive
          (non-editorial) changes to the standard.  If there
          are any substantive changes made, it will result
          in another public review period, which will delay
          the standard for at least one calendar year.

        - Assuming that there are no substantive changes to
          the standard after the next public review period,
          there should be a ratified standard before the end
          of 1988.

     If the C Language Standard can be completed before the
     end of the year, it could mean a lot for POSIX system
     implementors.  Since the .1 standard will not be really

C Language, January 21, 1988    Shane P. McCarron, NAPS Inc.


Standards Update           - 2 -          USENIX Association

     a standard until June, it is unlikely that vendors will
     be able to complete an implementation before the end of
     1988 in any event.  If they could release a system that
     supported both Standard C and POSIX, it would be a real
     shot in the arm for application developers.  A delay of
     another year on Standard C would mean that application
     developers must write code under POSIX that could very
     well be broken under an ANSI C Conforming compiler.

C Language, January 21, 1988    Shane P. McCarron, NAPS Inc.


Volume-Number: Volume 13, Number 3

From uucp  Sun Jan 24 12:20:56 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09875; Sun, 24 Jan 88 12:20:56 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (3 of 4): NBS FIPS
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 24 Jan 88 17:20:46 GMT
Apparently-To: std-unix-list
Status: O


                      Standards Update
        An update on UNIX and C Standards Activities

                      January 21, 1988

             Written for the USENIX Association
              by Shane P. McCarron, NAPS Inc.

   - NBS POSIX FIPS

     One other item that is of concern to system
     implementors and application developers alike is the
     POSIX FIPS that is being announced by NBS this month.
     This FIPS will be used by most federal agencies when
     drafting Request for Proposals (RFPs) for many classes
     of applications.

     Just what is NBS going to require?  Well, the NBS POSIX
     FIPS is based on POSIX D12, the draft that went out to
     the balloting group.  The final POSIX standard may be
     considerably different than this, but NBS has assured
     the .1 working group that they will incorporate the
     substantive changes in the standard into their FIPS
     when the standard is complete.

     So, if NBS is going to specify POSIX as the FIPS, what
     are we worried about?  Well, in order to increase
     consensus and support as many existing implementations
     as possible, POSIX has a lot of "options" in it.  NBS
     felt that these "options" made it difficult for
     applications developers to write applications that used
     the nice facilities of POSIX (they are right), so they
     are requiring that many of these options be included in
     a FIPS conforming implementation.  For systems
     implementors, this means that you had better include
     all of these options if you want to sell to the federal
     government.  For applications developers, it means that
     if your customer base is the federal government, you
     can use these facilities without fear - they will be
     there.

     What are these options?  Well, the following is an
     excerpt from the NBS POSIX FIPS draft specification.

     As an aside, it is important to note that many of these
     so-called "options" are not really options at all, but
     rather cases in which there was some ambiguity as to
     how the system would function.  I will indicate in the
     following list some examples of real options and their
     opposites for clarity.

NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.


Standards Update           - 2 -          USENIX Association

        - The term appropriate privileges shall be
          synonymous with the term super-user.

          This is not really an option, but rather a
          clarification being introduced by the NBS people.
          The term "appropriate privileges" was introduced
          into the standard to provide for secure
          implementations of POSIX.  By indicating that
          certain facilities of POSIX require "appropriate
          privilege", the door was left open for
          implementations where processes could have subsets
          of the power normally granted to a monolithic
          "super-user".  In fact, the above requirement is
          incorrect.  You could not simply replace the term
          "appropriate privileges" with the term "super-
          user" throughout the standard and have it make any
          sense.  However, we get the idea.

        - A null pathname shall be considered invalid and
          generate an error (2.10.3, lines 894 - 896).

        - The use of the chown() function shall be
          restricted to a process with super-user privileges
          (2.10.4, lines 924 - 926).

          This is an example of a real option in POSIX.  If
          the macro _POSIX_CHOWN_RESTRICTED is defined, it
          means that only a process with "appropriate
          privilege" can change to owner of a file.  This is
          in conflict with the current System V definition
          of how chown works, btu is more in line with
          trusted implementations.  Users should not be able
          to "give away" files.

        - Only the super-user shall be allowed to link or
          unlink directories (2.10.4, lines 938 - 939).

          Another useful option.  A portable application may
          need to know whether it requires "approprite
          privileges" to move directories around.

        - The owner of a file may use the utime() function
          to set file timestamps to arbitrary values
          (2.10.4, lines 943 - 945).

        - The implementation shall support a value of
          {NGROUPS_MAX} greater than or equal to eight (8)
          (2.9.2).  An implementation may provide an option
          for setting {NGROUPS_MAX} to a value other than
          eight (8).

NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.


Standards Update           - 3 -          USENIX Association

          The POSIX standard is still in the ballot
          resolution process.  When it went to ballot it
          defined the BSD-style supplementary groups
          feature.  this says that there is a group-id
          associated with a process, but that there may be
          additional, supplementary groups also.

          As of this writing, the definition has been
          changed to a more flexible definition.  There will
          now be an array of group IDs associated with a
          process.  Although this change has not been
          accepted by the full balloting group yet, I think
          that it will be.

        - The implementation shall support the setting of
          the group-ID of a file (when it is created) to
          that of its parent directory (2.10.4, lines 934 -
          937).  An implementation may provide a
          programmable selectable means for setting the
          group-ID of a file (when it is created) to the
          effective group-ID of the creating process.

          This is another example of a true option.  Here
          the FIPS is specifying the BSD method of creating
          files.  This method make a lot of sense in a
          multiple group per process environment.  However,
          they also allow the System V behavior.

        - The use of chown() shall be restricted to changing
          the group-ID of a file to the effective group-ID
          of a process or when {NGROUPS_MAX} > 0, to one of
          its supplementary group-IDs (2.10.4, lines 927 -
          930).

        - The exec() type functions shall save the effective
          user- ID and group-ID (2.10.3, lines 902 - 903).

          This mirrors the System V behavior.

        - The kill() function shall use the saved set user-
          ID of the receiving process instead of the
          effective user-ID to determine eligibility to send
          the signal to a process (2.10.3, lines 891 - 893).

          This is also similar to System V.

        - When a session process group leader executes an
          exit() a SIGHUP signal shall be sent to each
          member of the session process group (2.10.3 lines
          880 - 883).

NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.


Standards Update           - 4 -          USENIX Association

        - The terminal special characters defined in
          Sections 7.1.1.10 and 7.1.2.7 can be individually
          disabled by using the value specified by
          _POSIX_V_DISABLE (2.10.4, lines 946 - 949;
          7.1.1.10;  7.1.2.7).

        - The implementation shall support the
          _POSIX_JOB_CONTROL option 2.10.3, lines 884 -
          886).

          Although I have not described how Job Control
          works under POSIX, suffice it to say that it is
          confusing at best.  The ballot resolution group is
          still trying to decide how to resolve the problems
          pointed out during balloting.

        - The implementation shall provide a single utility
          for reading and writing POSIX data interchange
          format files (10.).  This utility shall be capable
          of reading USTAR and CPIO data interchange formats
          without requiring the format to be specified.  The
          implementation shall write CPIO data interchange
          format when no option on format type is specified.

        - Pathnames longer than {NAME_MAX} shall be
          considered invalid and generate an error (2.10.4,
          lines 940 - 942).

        - When the rename(), unlink() or rmdir() function is
          unsuccessful because the conditions for [EBUSY]
          occur, the implementation shall report the [EBUSY]
          errno (5.5.1.4, lines 481 - 482; 5.5.2.4, lines
          523 - 524; 5.5.3.4, lines 593 - 594).

        - When the rename() function is unsuccessful because
          the conditions for [EXDEV] occur, the
          implementation shall report the [EXDEV] errno
          (5.5.3.4, lines 593 - 594).

        - When the fork() or exec type function is
          unsuccessful because the conditions for [ENOMEM]
          occur, the implementation shall report the
          [ENOMEM] errno (3.1.1.4, line 54; 3.1.2.4, lines
          175 - 176).

        - When the getcwd() function is unsuccessful because
          the conditions for [EACCES] occur, the
          implementation shall report the [EACCES] errno
          (5.2.2.4, lines 148 - 149).

NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.


Standards Update           - 5 -          USENIX Association

        - When the chown() or wait2() function is
          unsuccessful because the conditions for [EINVAL]
          occur, the implementation shall report the
          [EINVAL] errno (3.2.1.4, line 272; 5.6.5.4, line
          857).

        - The implementation shall detect an [EFAULT] errno
          condition (2.5, lines 554 - 558). The
          implementation must state as part of the required
          documentation; (1) the conditions when an [EFAULT]
          is detected and an [EFAULT] errno is generated and
          (2) those conditions, if any, when [EFAULT] may
          not be detectable.

        - The tcsetattr() function shall only set the
          parameters supported by the underlying hardware
          associated with the terminal (7.2.1.2, line 502).

        - An interrupted write() function shall return a
          count of the number of bytes successfully
          transferred from the application program to the
          system (6.4.2.2, lines 195 - 196; 6.4.2.4. lines
          240 - 242).

        - An implementation may provide errno [ENOEXIST] in
          place of errno [EACCES].

        - A POSIX FIPS implementation shall successfully
          PASS the NBS-PCTS validation suite.

     From all of these options, I am sure that it is obvious
     that there is room for considerable variation in the
     POSIX standard.  The FIPS goes a long way towards
     firming up an otherwise wishy-washy document.  Since
     many system implementors want to sell to the US
     Government, it is probable that all of the above
     requirements will be available on a majority of POSIX
     conforming systems.  This is excellent news for
     application developers who want to take advantage of
     some of the additional facilities introduced in POSIX
     as optional.

NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.


Volume-Number: Volume 13, Number 4

From uucp  Sun Jan 24 12:21:54 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA10010; Sun, 24 Jan 88 12:21:54 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (4 of 4): IEEE P1003
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 24 Jan 88 17:22:36 GMT
Apparently-To: std-unix-list
Status: O


                      Standards Update
        An update on UNIX and C Standards Activities

                      January 21, 1988

             Written for the USENIX Association
              by Shane P. McCarron, NAPS Inc.

Status of the IEEE P1003 Working Groups:

   - 1003.1 - System Services Interface

     The .1 working group has reached an interesting point
     in its life.  Since the standard they have produced is
     now in final ballot and ballot resolution, the working
     group in effect has nothing more to do.  At the
     December meeting they tried to decide what, if
     anything, should be done by this body in the future.
     Although no decision on this was made, many good
     options were suggested.

     Most promising among these is the design of a language
     independent description of POSIX.  One of the
     requirements that ISO made of POSIX when it was adopted
     as a Draft Proposed Standard last fall was that at some
     point in the future it be described in such a way that
     they functionality could be understood without an
     understanding of the C language.  ISO recognized that
     it was unrealistic to make this a requirement before
     adopting the standard, but felt that it was reasonably
     important.  I feel that this is something the working
     group will be taking on soon after the Full Use
     Standard is approved by IEEE.

   - 1003.2 - Shell and Tools Interface

     The Shell and Tools group is operating under a very
     ambitious schedule.  The National Bureau of Standards
     (NBS) has indicated that they are going to declare a
     Federal Information Processing Standard (FIPS) based on
     the command set in the .2 standard, and that they are
     going to do so in the summer of '88.  This working
     group only started serious work 1 year ago, and has
     already produced a larger document than the .1 group
     did in 4.  The group is working hard to make sure that
     the command set is locked down before the deadline
     being imposed by NBS.

     Unfortunately, this has the consequence that many
     decisions are being made as rapidly as possible.  I am
     afraid that the resulting standard may be one that is

IEEE P1003, January 21, 1988    Shane P. McCarron, NAPS Inc.


Standards Update           - 2 -          USENIX Association

     flawed, if only because the group is moving forward too
     fast.  On the other hand, the .1 group was guilty of
     exactly the opposite, and NBS pressure has forced that
     group to really get its act together.  It has proven to
     be a boon there, and it may do so here as well.

     The Shell and Tools group has a milestone schedule
     something like:

           Date        Milestone

           Mar '88     Command Selection frozen;
                       75% described.

           Jun '88     100% commands described;
                       functional freeze

           Oct '88     Clean-up, slack; produce
                       "mock ballot" for draft (#8);
                       international signoff.

           Jan '89     Resolve mock objections;
                       produce balloting draft (#9)

           Apr '89     Resolve ballot objections;
                       produce final standard.

           Jul '89     Final standard approved by IEEE

     This may not appear to be all that hectic a pace, but I
     can assure you that it is.  When I say that the
     commands are 100% described, it means that the current
     functionality of each command that has been included in
     the standard (a substantial part of the current "un*x"
     command set) is described in painful detail.  The goal
     of the standard is to describe each command in such a
     way that a person who has never seen a un*x machine can
     write the commands from scratch.  It's a lot of text.
     With about 75% of the commands in, and those being
     about 75% described (albeit incorrectly in some cases)
     the document is now approaching 400 pages.  In a future
     report I will tell you just what is involved in a
     command description.  We don't have the space this time
     :-)

   - 1003.3 - Testing and Verification

     This is another group that has been very active in the
     last year or so.  They have the dubious honor of
     figuring out how to test that implementations of the .1
     standard are actually conforming.  Although the IEEE is

IEEE P1003, January 21, 1988    Shane P. McCarron, NAPS Inc.


Standards Update           - 3 -          USENIX Association

     not going to be providing any validation services or
     rating and systems, P1003 thought that it was important
     that they define what parts of the system should be
     tested in what ways.

     The .3 group seems to be on track for balloting within
     the next 6 to 9 months.  There work is very far along,
     and a verification suite is already being worked on by
     the NBS based on the .3 assertion list about POSIX.
     Although the .3 document will not be as earth-
     shattering as POSIX, it is a still a very important
     step - actually showing how to test conformance to a
     standard at the same time you are defining one.

   - 1003.4 - Real Time

     Until recently, all the real time considerations in
     POSIX were being looked into by a /usr/group technical
     committee.  Last fall that committee decided that their
     research was mature enough that they could actually
     start the work of producing a standard about it.  The
     real time work promises to add much of the
     functionality that I and many others feel is absolutely
     necessary in POSIX.  Things like semaphores, shared
     memory, and event processing.  All of those inter-
     process communication things that were left out of the
     .1 standard because they just did not have the time.

     Unfortunately, there is quite a bit of dissension as to
     how all of these things should be implemented.  Not
     just IPC, but also contiguous files, timers, and those
     things that a real time application would need to
     really be real time.  After talking to some of the
     people who attended the December meeting, I would guess
     that this group has a long way to go.

     However, what will happen when they get there?  At this
     time I'm guessing that the .4 document will be
     positioned as a supplement to the .1 standard.  It
     should require no changes to the .1 standard, and will
     probably be a set of optional facilities, as job
     control and some others are already.  When this
     standard is finally produced, it will answer many of
     the objections we have heard to POSIX all along.  I am
     sure that it will be well received.  Let's hope that it
     can be timely enough to be useful.

IEEE P1003, January 21, 1988    Shane P. McCarron, NAPS Inc.

Volume-Number: Volume 13, Number 5

From uucp  Mon Jan 25 13:29:52 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA06822; Mon, 25 Jan 88 13:29:52 EST
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update (3 of 4): NBS FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 25 Jan 88 01:27:24 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!Sun.COM!guy (Guy Harris)

This may want to be forwarded to Shane, rather than posted; unfortunately,
I don't remember his email address.

[ He's [e-mail] or uunet!rutgers!umn-cs!bungia!ahby,
but this looks like a useful correction of a technical detail
(one I missed on review) that should be posted. -mod ]

        - Only the super-user shall be allowed to link or
          unlink directories (2.10.4, lines 938 - 939).

          Another useful option.  A portable application may
          need to know whether it requires "approprite
          privileges" to move directories around.

No portable application needs "appropriate privileges" to move directories
around; it can use "rename()".  The correct way to move anything under a POSIX
implementation is to use "rename()", not "link()" and "unlink()".

Volume-Number: Volume 13, Number 6

From uucp  Tue Jan 26 23:41:25 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA08839; Tue, 26 Jan 88 23:41:25 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix
Subject: calendar of UNIX-related events
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John S. Quarterman)
Date: 27 Jan 88 04:07:51 GMT
Apparently-To: std-unix-archive
Status: O

Here is a combined calendar of planned conferences, workshops, or
standards meetings by various organizations.  I compiled it for
my own use and thought it might be of some public interest.
Most of this information came from the various conference organizers,
although some was taken from ;login: (USENIX), 13, 1, Jan/Feb 1988
and CommUNIXations (/usr/group), VII, 6, Nov/Dec 1987.

Abbreviations:  U for UNIX, W for Workshop, C for Center.
The sponsors of the USENIX, EUUG, and AUUG conferences are the
organizations of the same name, and the sponsor of UniForum is
/usr/group.  Dates and places for IEEE 1003 after Oct 1988 are
tentative, and also for the 1992 UniForum.

year mon days       conference name      (sponsor,) (hotel,) location

1988 Feb 8-11       UniForum             Infomart, Dallas, TX
1988 Feb 9-12       USENIX               Grand Kempinski, Dallas, TX
1988 Mar 14-18      IEEE 1003            Ritz-Carlton, Washington, DC
1988 Apr 11-15      EUUG                 QE II Conference C, London
1988 May 3-5        U Exposition         AFUU, Palais des Congress, Paris
1988 May 12-13      Real-Time W          USENIX/IEEE, Omni Shoreham, Washington
1988 May 17-19      UNIX 88/etc.         /usr/group/cdn, Convention C, Toronto
1988 Jun 7-9        COMUNIX              /usr/group/UK, Alexandra Palace, London
1988 Jun 9-11       NZSUGI               Wellington, New Zealand
1988 Jun 20-24      USENIX               Hilton, San Francisco, CA
1988 Jun 27-Jul 1   IEEE 1003            Colorado Springs, CO

1988 Jul            U Symposium          JUS, Tokyo, Japan
1988 Aug 2-4        UniForum/DC          Washington Hilton, Washington, DC
1988 Aug 29-30      U Security W         USENIX, Portland, OR
1988 Sep 13-15      AUUG                 Melbourne, Australia
1988 Sep 26-27      U&Supercomputing W   USENIX, Pittsburgh, PA
1988 Oct 3-7        EUUG                 Lisbon, Portugal
1988 Oct 10-14      IEEE 1003            Hawaii
1988 Oct 17-19+     ISO SC22 & WG15      Tokyo, Japan
1988 Oct 17-21      C++ Conference       USENIX, Denver, CO
1988 Oct            UNIX Expo            New York, NY
1988 Nov 17-18      Large Installation   Syst. Adm. W II, USENIX, Monterey, CA
1988 Nov            U Symposium          JUS, Osaka, Japan
1988 Dec            Sun User Group       southern U.S.A.
1988 Dec            UNIX Fair            JUS, Tokyo, Japan

1989 Jan            IEEE 1003            Ft. Lauderdale, FL
1989 Jan 31-Feb 3   USENIX               Town and Country, San Diego, CA
1989 Feb 28-Mar 3   UniForum             Moscone Center, San Francisco, CA
1989 Apr            IEEE 1003            Minneapolis-St. Paul, MN
1989 Jun 12-16      USENIX               Hyatt Regency, Baltimore, MD
1989 Jun            IEEE 1003            Monterey, CA
1989 Oct            IEEE 1003            Brussels (or Amsterdam)

1990 Jan 23-26      USENIX               Washington, DC
1990 Jan 23-26      UniForum             Washington Hilton, Washington, DC
1990 Jan            IEEE 1003            New Orleans, LA
1990 Jun 11-15      USENIX               Marriott, Anaheim, CA

1991 Jan 22-25      USENIX               Dallas, TX
1991 Jan 22-25      UniForum             Infomart, Dallas, TX
1991 Jun 10-14      USENIX               Opryland, Nashville, TN

1992 Jan 21-24      UniForum (?)         Moscone Center, San Francisco CA

Volume-Number: Volume 13, Number 8

From uucp  Wed Jan 27 02:00:26 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09052; Tue, 26 Jan 88 23:43:58 EST
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 27 Jan 88 04:19:38 GMT
Apparently-To: std-unix-archive
Status: O

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.
I'm cross-posting it to comp.org.usenix and comp.unix.questions
because there might be interest there.  There is also a lengthy article
on access to UNIX-related standards, but that's only in comp.std.unix.

Corrections and additions to this article are solicited.
Recent additions:  Sun User Group, and dates for AUUG and NZSUGI Conferences
and USENIX Workshops.  Corrected USENIX Conference dates, EUUG fax number,
IX Magazine telephone number.  Computing Systems and CommUNIXations listed
under magazines.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG,
        DECUS UNIX SIG, Sun User Group
newsletters:    ;login:, /usr/digest, EUUGN, AUUGN, NUZ
journal:    Computing Systems
magazines:    CommUNIXations, UNIX REVIEW, UNIX/WORLD, IX Magazine,
        UNIX Systems, UNIX Magazine

Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.

UNIX is a Registered Trademark of AT&T.


USENIX is ``The Professional and Technical UNIX(R) Association.''

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        U.S.A.
        [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:

    Feb  9-12 1988    Grand Kempinski Hotel, Dallas, TX, concurrent w/UniForum
    Jun 20-24 1988    Hilton Hotel, San Francisco, CA
    Jan 31-Feb 3 1989 Town & Country Inn, San Diego, CA
    Jun 12-16 1989    Hyatt Regency, Baltimore, MD
    Jan 23-26 1990    Washington, DC
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA
    Jan 22-25 1991    Dallas
    Jun 10-14 1991    Opryland, Nashville

They also sponsor workshops, such as
    May 12-13 1988    Omni Shoreham Hotel, Washington, DC
        Fifth Workshop on Real-Time Software and Operating Systems
        IEEE Computer Society and USENIX Association
    Aug 29-30 1988    UNIX Security, Portland, OR
    Sep 26-27 1988    UNIX & Supercomputing, Pittsburgh, PA
    Oct 17-20 1988    C++ Conference (tentative), Denver, CO
    Nov 17-18 1988    Large Installation System Administration II, Monterey,CA

Proceedings for all conferences and workshops are available at
the door and by mail later.

USENIX publishes ``;login:  The USENIX Association Newsletter''
bimonthly.  It is sent free of charge to all their members and
includes technical papers.  There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.

In 1988, USENIX will start publishing a new refereed quarterly
technical journal, ``Computing Systems:  The Journal of the USENIX
Association,'' in cooperation with University of California Press.

They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership.  They distribute tapes of contributed software and are
pursuing expanding that activity.

There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.


/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        U.S.A.
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 8-11 1988    Infomart, Dallas, TX, concurrent with USENIX
    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.

Proceedings for all conferences are available at the shows and later
by mail.

/usr/group publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.

/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group.  This newsletter covers
product announcements and industry projections, and is sent biweekly
to General members of /usr/group and to non-member subscribers.

/usr/group has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Technical Committee
on areas that P1003 has not yet addressed.  They have recently produced
an executive summary, ``Your Guide to POSIX,'' and a technical overview
``POSIX Explored,'' and funded production of a draft of a ``Rationale and
Notes'' appendix for IEEE 1003.1.


EUUG is the European UNIX systems Users Group.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        Telephone [phone]
        Telefax [phone]
        uunet!mcvax!inset!euug
        [e-mail]

They have a newsletter, EUUGN, and hold two conferences a year:
    11-15 April 1988, London, England
    3-7 October 1988, Lisbon, Portugal


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds at least one conference a year, usually in the spring
(August or September).  The next one will be in Melbourne on 13-15
September 1988, will be the first three day meeting, will have a larger
equipment exhibition than any before, and will be professionally
organized for the first time.

They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.


The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
and publishes a newsletter, ``NUZ.''

        New Zealand UNIX Systems User Group
        P.O. Box 585
        Hamilton
        New Zealand
        [phone]

The next and fifth annual meeting is the New Zealand UNIX Systems User Group
(NZUSUGI) 1988 Conference, June 9-11 1988, in Wellington, New Zealand.

If you wish to present a paper, acceptance of which entitles you to a free
conference registration, please contact the local speakers organiser,
Dr Dick Cooper, ADATA, PO Box 2555, Christchurch, New Zealand,
[e-mail]   or ...uunet!vuwcomp!cantuar!dick

If you would just like to attend, please respond to Ray Brownrigg, including
a postal address for the delivery of further information as it becomes
available.  Registration forms are expected to be available in February.

        UUCP: {utai!calgary,uunet}!vuwcomp!dsiramd!ray
        ACSnet:    [e-mail][@munnari]
        Ray Brownrigg
        Applied Maths Div, DSIR
        PO Box 1335
        Wellington
        New Zealand


The Korean UNIX User Group has a software distribution service and a newsletter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Chungnam 300-32
        Republic of Korea
        [phone]


The Japan UNIX Society has two meetings a year, and a newsletter.

        Japan UNIX Society
        #505 Towa-Hanzomon Corp. Bldg.
        2-12 Hayabusa-cho
        Chiyoda-ku, Tokyo 102
        Japan
        [phone]


There are similar groups in other parts of the world.  If such a group
wishes to be included in later versions of this access list, they
should please send me information.

There is a partial list of national organizations in the November/December
1987 CommUNIXations.



DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held twice a year.

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        U.S.A.
        [phone]

See also the USENET newsgroup comp.org.decus.


The Sun User Group (SUG) is an international organization that promotes
communication among Sun users, OEMs, third party vendors, and Sun
Microsystems, Inc.  SUG sponsors conferences, collects and distributes
software, produces the README newsletter and T-shirts, sponsors local
user groups, and communicates members' problems to Sun employees and
management.

    Sun Microsystems User Group, Inc.
    2550 Garcia Avenue
    Mountain View, CA  94043
    U.S.A.
    [phone]
    [e-mail]
    sun!users

They have not set a date/location for the 1988 conference yet, but are
actively looking for a hotel (with good pricing and lots of room).
They've narrowed it down to several locations - Miami/Tampa Florida,
Houston/Dallas Texas, and New Orleans LA.  The date will probably be
very early December, 1988.


The main general circulation (more than 10,000 copies per issue) magazines
about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    U.S.A.                U.S.A.
    [phone]            [phone]

    IX Magazine            UNIX Systems
    Storyplace Ltd.            Eaglehead Publishing Ltd.
    137-139 Euston Road        Maybury Road
    London NW1 2AU            Woking, Surrey GU21 5HX
    England                England
    [phone]            [phone]

    UNIX Magazine
    Jouji Ohkubo
    c/o ASCII Corp.
    [e-mail]
    [phone]
    fax: [phone]
    telex: 242-6875 ASCIIJ

In addition:

    Computing Systems        CommUNIXations
    USENIX Association        /usr/group
    P.O. Box 2299            4655 Old Ironsides Drive, Suite 200
    Berkeley, CA 94710        Santa Clara, California 95054
    U.S.A.                U.S.A.
    [phone]            [phone]

Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters.  The following
information about bookstores was taken from the same issue.  In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.

    Computer Literacy Bookshop    UNIX Book Service
    2590 No. First St.        35 Bermuda Terrace
    San Jose, CA 95131        Cambridge, CB4 3LD
    U.S.A.                England
    [phone]        [phone]

    Cucumber Bookshop        Jim Joyce's UNIX Book Store
    5611 Kraft Ave.            47 Potomac St.
    Rockville, MD 20852        San Francisco, CA 94117
    U.S.A.                U.S.A.
    [phone]            [phone]

Volume-Number: Volume 13, Number 9

From uucp  Wed Jan 27 03:17:48 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA08534; Tue, 26 Jan 88 23:37:35 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 15 Feb 88 06:00:00 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 27 Jan 88 04:02:21 GMT
Apparently-To: std-unix-archive
Status: O


This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.
Change from last posting:  all IEEE 1003 subcommittee chairs listed.


Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
    1003.3 (testing and verification), 1003.4 (real time),
    1003.5 (ADA binding), 1003.6 (security), 1003.0 (POSIX guide).
NBS FIPS.
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing.
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee.  They published the 1003.1 "POSIX" Trial Use
Standard in April 1986.  According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95, with bulk purchasing discounts
available.  Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:

        IEEE Computer Society
        P.O. Box 80452
        Worldway Postal Center
        Los Angeles, Ca. 90080

Include a check for $19.95 + $4 for shipping and handling.  For UPS
shipping, add another $4.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Spring 1988.
Initial balloting is completed, and ballot resolution is in progress:
it's too late to ballot if you haven't already.


IEEE has brought the 1003.1 effort brought into the International
Organization for Standardization (ISO) arena.  IEEE 1003.1 Draft 12
is also a ``Draft Proposed International Standard (ISO DP)'' under
SC22 WG15.  The convenor is Jim Isaak:  see below for his address.
There is a U.S. Technical Advisory Group (TAG) to ISO SC22 WG15:
the chair is Donn Terry of HP.

The National Bureau of Standards is producing a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1.  It will probably
be available before the Full Use Standard, and may reflect Draft 12,
rather than the final 1003.1 standard.  For information, contact:

        Roger Martin
        National Bureau of Standards
        Building 225
        Room B266
        Gaithersburg, MD  20899
        [phone]


Machine readable copies of the IEEE 1003.1 Trial Use Standard are not
and will not be available.  The same applies to copies of later drafts.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Tel.: [phone]
        Fax.: [phone]
        decvax!isaak
        [e-mail]
        Digital Equipment
        ZK03-3/Y25
        110 Spit Brook Rd.
        Nashua, NH  03062-2698

Sufficiently interested parties may join the working group.

The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                co-chairs
1003.0    POSIX Guide            Al Hankinson (NBS), Kevin Lewis (DEC)
1003.1    Systems Interface        Jim Isaak (DEC), Donn Terry (HP)
1003.2    Shell and Tools Interface    Hal Jespersen (UniSoft), Don Cragun (Sun)
1003.3    Verification and Testing     Roger Martin (NBS), Carol Raye (AT&T)
1003.4    Real Time             Bill Corwin (Intel)
1003.5    Ada Binding for POSIX        Terry Fong (USArmy), Stowe Boyd(Compass)
1003.6    Security            Dennis Steinauer (NBS), Ron Elliot (IBM)

Inquiries regarding any of the subcommittees should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are:

1988 March 14-18    Ritz-Carlton Hotel, Washington, DC
1988 June 27-July 1    Colorado Springs, CO
1988 October 10-14    Hawaii
1988 October 17-19+    ISO SC22 Advisory Group & WG15 - Tokyo, Japan

1989 January        Ft. Lauderdale, FL
1989 April        Minneapolis-St. Paul, MN
1989 June        Monterey, CA
1989 October        Brussels (or Amsterdam) (Thought: EC host)
1990 January        New Orleans, LA

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    utilities for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about clarifying
the scope of the 1003.2 standard in regard to its relationship with
1003.1.  The Working Group is attempting to produce a standard that
will assume the structure and philosophy of a POSIX system is
available, but it will not require a fully conforming implementation as
a base.  For example, it should be feasible to eventually produce a
1003.2 interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and utilities
didn't need them).  However, the proposed standard will *not* be
unnecessarily watered down simply to allow non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Mike Lambert from X/OPEN.
The two from USENIX and /usr/group are also representatives to the U.S.
TAG to ISO SC22 WG15.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
An article related to this one appeared in the September/October 1986
;login: (The USENIX Association Newsletter).  I'm also currently on the
USENIX Board of Directors.  Comments, suggestions, etc., may be sent to

        John S. Quarterman
        Texas Internet Consulting
        701 Brazos, Suite 500
        Austin TX 78701-3243
        [phone]
        uunet!usenix!jsq
        [e-mail]

For comp.std.unix:
Comments:    uunet!std-unix-request [e-mail]
Submissions:    uunet!std-unix        [e-mail]

The November/December 1987 issue of CommUNIXations (the /usr/group magazine)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in June 1987.

If you are interested in starting another /usr/group working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above.

/usr/group Working Group on Distributed File System:
    Art Sabsevitz            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6248            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    John Wu                Laurie Goudie
    Charles River Data Systems    Santa Cruz Operation
    983 Concord St.,        400 Encinal
    Framingham, MA 01701        Santa Cruz, CA 95060
    617-626-1000            408-458-1422

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

/usr/group Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]


/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail]


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

Ask for the X3.159 draft standard.  The price is $65.


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        Tel: [phone]
        Fax: [phone]

/usr/group also publishes an eight page document, ``Your Guide to POSIX,''
explaining what IEEE 1003 is, and a nineteen page document, ``POSIX Explored,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations.  Contact /usr/group at the above address
for details.


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (at time of publication, Bull, DEC, Ericsson, Hewlett-Packard,
ICL, NIXDORF, Olivetti, Philips, Siemens and Unisys and subsequently
augmented by AT&T) who have produced a document intended to promote
the writing of portable applications.  They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.

Comments, suggestions, error reports, etc., for Issue 2 of the Green Book
may be mailed directly to:

        [e-mail]
        uunet!mcvax!inset!xopen!xpg2

Information about X/OPEN can be requested from:

        Mike Lambert
        Technical Director
        X/OPEN Ltd
        c/o ICL BRA01
        Lovelace Road
        Bracknell
        Berkshire
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:

        Howard Press
        c/o USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710

        415-528-8649
        {ucbvax,decvax}!usenix!office

4.3BSD User's Manual Set (3 volumes)        $25.00
    User's Reference Manual
    User's Supplementary Documents
    Master Index

4.3BSD Programmer's Manual Set (3 volumes)    $25.00
    Programmer's Reference Maual
    Programmer's Supplementary Documents, Volume 1
    Programmer's Supplementary Documents, Volume 2

4.3BSD System Manager's Manual (1 volume)    $10.00

Unfortunately, there are some license restrictions.
Contact the USENIX office for details.

Volume-Number: Volume 13, Number 7

From uucp  Mon Feb  1 15:41:03 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA11324; Mon, 1 Feb 88 15:41:03 EST
From: Shane P. McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update (3 of 4): NBS FIPS
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: uunet!rutgers!umn-cs!quest!bungia!ahby (Shane P. McCarron)
Organization: Bugoslavian Embassy, St. Paul, MN
Date: 28 Jan 88 03:26:51 GMT
Apparently-To: std-unix-archive
Status: O

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


In article <[e-mail]> [e-mail] (Guy Harris) writes:
>From: uunet!Sun.COM!guy (Guy Harris)
>
>This may want to be forwarded to Shane, rather than posted; unfortunately,
>I don't remember his email address.
>
>[ He's [e-mail] or uunet!rutgers!umn-cs!bungia!ahby,
>but this looks like a useful correction of a technical detail
>(one I missed on review) that should be posted. -mod ]
>
>        - Only the super-user shall be allowed to link or
>          unlink directories (2.10.4, lines 938 - 939).
>
>          Another useful option.  A portable application may
>          need to know whether it requires "approprite
>          privileges" to move directories around.
>
>No portable application needs "appropriate privileges" to move directories
>around; it can use "rename()".  The correct way to move anything under a POSIX
>implementation is to use "rename()", not "link()" and "unlink()".

Mea culpa, mea culpa :-)

Of course Guy is right.  No portable application may ever require
appropriate privilege and still be portable.  Especially since that
privilege will be very hard to define (or come by) in a trusted
environment.

What I was trying to imply was that if appropriate privilege is
required to link() and unlink() directories, and an application needs
that ability for some unforseeable reason, then it should probably
fail to compile on that instance of that implementation.

The rename() call is sufficient for changing the name of a directory,
but is hardly sufficient for creating multiple links to the same
directory, or some other arcane use.  It occurs to me that this may
only be possible today using symbolic links, but you get the idea.  My
advice to application developers is to not even try to write code that
requires anything that could be percieved as an option under POSIX.
If you stick to the minimal set, you will be safe.  Your application
won't do anything, but... :-)

Thanks for pointing out that rather glaring error.  I must be getting
senile.
--
Shane P. McCarron            UUCP: [e-mail]
Systems Analyst                ATT: [phone]

Volume-Number: Volume 13, Number 10

From uucp  Mon Feb  1 15:43:06 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA11370; Mon, 1 Feb 88 15:43:06 EST
From: Ariel J. Frank <CNUCE-VM.ARPA![e-mail]>
Newsgroups: comp.std.unix
Subject: Another addition
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Ariel J. Frank <[e-mail]>
Date: 28 Jan 88 12:00:54 GMT
Apparently-To: std-unix-archive
Status: O

From: Ariel J. Frank <[e-mail]>

Hello John. Here is another addition to your useful 'Access to UNIX user
groups and Publications':

[ I will include it in the next posting, as well as posting it separately now.
-mod ]

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

AMIX, c/o IPA
P.O. Box 919
Ramat-Gan
Israel, 52109
Tel: [phone],715772
[e-mail]
[e-mail]

AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli Processing
Association (IPA). AMIX has a yearly conference (next one on 4-6 July 1988)
and a yearly workshop (last one was in November).

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

Please ACK its receival. Thanks, Ariel Frank - AMIX Chairperson.

    Ariel J. Frank
    Deputy Chairperson
    Dept. of Mathematics and Computer Science
    Bar Ilan University
    Ramat Gan, Israel 52100
    Tel: [phone]

    [e-mail]
    BITNET: ariel@bimacs (also F68388@barilan)
    ARPA:   [e-mail]
    CSNET:  ariel%bimacs.bitnet%wiscvm.wisc.edu@csnet-relay
    UUCP:   {mcvax,seismo}!humus!bimacs!ariel


Volume-Number: Volume 13, Number 11

From uucp  Tue Feb  2 20:06:28 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA23063; Tue, 2 Feb 88 20:06:28 EST
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: USENIX standards BOF
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Feb 88 00:22:10 GMT
Apparently-To: std-unix-archive
Status: O

There will be a Birds of a Feather (BOF) on standards at USENIX on Wednesday,
10 February 1988, coordinated by John S. Quarterman, Shane P. McCarron, and
whoever else wants to help.

Volume-Number: Volume 13, Number 12

From uucp  Wed Feb  3 21:30:01 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA01873; Wed, 3 Feb 88 21:30:01 EST
From: Kelly Chang <[e-mail]>
Newsgroups: comp.std.unix
Subject: BOF sessions at Dallas Usenix sponsored by Sun User Group
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: infmx!kchang (Kelly Chang)
Organization: Informix Software Inc., Menlo Park, CA.
Date: 2 Feb 88 08:55:46 GMT
Apparently-To: std-unix-archive
Status: O

[ I found this in news.announce.conferences.  -mod ]

From: [e-mail] (Kelly Chang)

- - -
    GOING TO USENIX IN DALLAS?

The Sun User Group cordially invites you to attend
two SUG sponsored BOF sessions at USENIX:

WHO:    Sun Microsystems, Inc.
    MIT - Project Athena

WHAT:    Standards and Application Binary Interface
    (Sun Microsystems, Inc.)
    6:00pm-8:00pm

    Secure NFS - Solutions
    (Sun Microsystems, Inc. & MIT - Project Athena
    8:00pm-10:00pm

WHEN:    Thursday, February 11th

WHERE:    Lalique Ballroom - Section 2
    Grand Kempinski Hotel
    Dallas, Texas


If you have any questions, please contact the Sun User Group
at 415-691-4343 or send email to:

    sun!users
or
    [e-mail].  Thank you.

Sanford "Sandy" Meltzer
Executive Director, SUG

Volume-Number: Volume 13, Number 13

From uucp  Thu Feb  4 17:38:01 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA17221; Thu, 4 Feb 88 17:38:01 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards BOF at USENIX
Message-Id: <[e-mail]>
Reply-To: uunet!hao!scicom!qetzal!upba!cory (Cory Dekker)
Date: 3 Feb 88 20:08:43 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!hao!scicom!qetzal!upba!cory (Cory Dekker)

    Any more information you have on exactly where and when
    would be appreciated.

                Thanks in advance,
                    -Cory

[ 8PM Wednesday, 10 February, at the Grand Kempinski (the USENIX hotel). -mod ]

Volume-Number: Volume 13, Number 14

From uucp  Mon Feb 15 21:39:24 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA14596; Mon, 15 Feb 88 21:39:24 EST
From: John Chambers <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update (3 of 4): NBS FIPS
Summary: Is rename() guaranteed to work across directories?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: minya!jc (John Chambers)
Organization: home
Date: 15 Feb 88 20:44:05 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (John Chambers)

[ This one got misplaced as I prepared to go to USENIX.
I don't really understand the question, but if it's whether the
rename function can be used to move directories, the answer is yes
(although the user command is mv).  -mod ]


> >No portable application needs "appropriate privileges" to move directories
> >around; it can use "rename()".  The correct way to move anything under a POSIX
> >implementation is to use "rename()", not "link()" and "unlink()".
>
> The rename() call is sufficient for changing the name of a directory, ...

One thing I've wondered is whether the standard will require implementors
to make things like rename("foo/bar/x","foo/x") work correctly.  This is
a serious omission in a great many Unix releases.

It's not at all a hypothetical issue.  I've seen a lot of cases where
a user (myself included) uses tar or cpio or some such to unpack a bunch
of files, intending them to go into foo/bar, and ending up with them all
in foo/bar/bar.  The usual result is "rm -rf foo/bar/bar" and starting
over.  It'd save a lot of grief if one could just say something like:
    rename foo/bar/bar foo/temp
    rename foo/temp foo/bar
and be done with it.  Of course, it'd be better if I could just type:
    rename foo/bar/bar foo/bar
and get the desired result, but that's probably too much to hope for. ;-)

Given the history of Unix releases, I wouldn't expect this to work when
foo/bar/bar is a directory, unless there is some argument stronger than
users' needs to convince the implementors.

--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)


Volume-Number: Volume 13, Number 16

From uucp  Tue Feb 16 11:18:31 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA03938; Tue, 16 Feb 88 11:18:31 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Dominic Dunlop <uunet!mcvax!sphinx.co.uk!domo>
Organization: Sphinx Ltd., Maidenhead, England
Date: 15 Feb 88 19:33:52 GMT
Apparently-To: std-unix-archive
Status: O

From: Dominic Dunlop <uunet!mcvax!sphinx.co.uk!domo>

In article <[e-mail]> you write:
>The main general circulation (more than 10,000 copies per issue) magazines
>about the UNIX system are
> ...
>    IX Magazine
>    Storyplace Ltd.
>    137-139 Euston Road
>    London NW1 2AU
>    England
>    [phone]

Please be aware that, as of the November, 1987 issue, IX magazine is now
Multi-User Computing, ``The Magazine for Open Systems Solutions''.  (Ho
hum.  I like to think that some single-user systems are open, too, but
never mind.)  While Storyplace is still the publisher, most other details
have changed, too:

    Multi-User Computing magazine
    Storyplace Ltd.
    42 Colebrook Row
    London  N1 8AF
    England
    [phone]

Further information:

    ISSN 0267-5692

    ``Multi-User Computing deals with open systems based on portable
    multi-user operating systems.  It is available free of charge to
    managers specifying or influencing the purchase of such systems; DP
    staff working with them; and management, development and marketing
    staff in supplier organisations.''

    Should this capacious net not catch you...

    UK subscription: pounds 18 per annum
    European subscription: pounds 25 per annum
    Rest of world subscription: pounds 25 per annum
--
Dominic Dunlop
[e-mail]  [e-mail]

Volume-Number: Volume 13, Number 17

From uucp  Thu Feb 18 01:41:18 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA20900; Thu, 18 Feb 88 01:41:18 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update (3 of 4): NBS FIPS
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: uunet!harvard.harvard.edu!haddock!karl (Karl Heuer)
Organization: Interactive Systems, Boston
Date: 17 Feb 88 22:42:48 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!harvard.harvard.edu!haddock!karl (Karl Heuer)

In article <[e-mail]> the moderator writes:
>I don't really understand the question, but if it's whether the rename
>function can be used to move directories, the answer is yes (although the
>user command is mv).

On at least one SysV-based system with a rename() system call and with
unprivileged mv command, the following can occur.

$ cat <<\! >rename.c
> main(c,v) char **v; { if (rename(v[1], v[2]) == -1) perror("rename"); }
> !
$ cc rename.c -o rename
$ ls
rename
rename.c
$ mkdir foo
$ mkdir foo/bar
$ mv foo/bar bar
mv: directory rename only
$ ./rename foo/bar bar
$ ls
bar
foo
rename
rename.c
$ ls foo
$ exit

As you can see, even though the system call works properly, `mv' on this
system attempts to enforce a restriction that the only thing you can do with a
directory is a `simple' rename (one where the `..' entry does not change).  My
reinterpretation of John Chamber's question has two parts:

(a) Does the standard require that the rename() function allow non-simple
renames of directories?

(b) Does the standard require that the mv command allow this?

[1003.1 doesn't say anything about mv, because that's in 1003.2.
I don't know offhand what 1003.2 says.  1003.2 people?  -mod]

Volume-Number: Volume 13, Number 18

From jsq  Sun Mar  6 19:06:37 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA28283; Sun, 6 Mar 88 19:06:37 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: IEEE 1003.1 ballot resolution fails
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 7 Mar 88 00:06:20 GMT
Apparently-To: std-unix-archive
Status: O

The recent 1003.1 ballot resolution process, which ended 25 February,
had sufficient logistical problems no usable new draft standard was
produced.  There will be another resolution period, probably in April,
probably for a period longer than ten days, and presumably with a complete
draft incorporating changes caused by the previous objections in addition
to a document explaining the changes and unresolved ballots that did not
produce changes.

My guess is that this means a 1003.1 Full Use Standard in June.

The recent report to the contrary in Computer Systems News is incorrect.

Volume-Number: Volume 13, Number 19

From uucp  Sun Mar 13 23:14:41 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA02555; Sun, 13 Mar 88 23:14:41 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 15 Apr 88 04:07:51 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Mar 88 03:45:03 GMT
Apparently-To: std-unix-archive
Status: O

This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.

Change from last posting:  Global (distributor of C standard) has moved.
The July IEEE 1003 and October ISO WG15 meetings have changed dates.

Also note that Shane McCarron now writes a quarterly summary report for
USENIX soon after each IEEE 1003 meeting for posting in comp.std.unix
and in ;login:, the Newsletter of the USENIX Association.

Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
    1003.3 (testing and verification), 1003.4 (real time),
    1003.5 (ADA binding), 1003.6 (security), 1003.0 (POSIX guide).
NBS FIPS.
/usr/group Technical Committee Subcommittees on distributed file system,
    network interface, graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing.
X3H3.6 (display committee)
X3J11 (C language)
/usr/group 1984 Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
IEEE is a trademark of the Institute of Electrical and Electronic Engineers,
    Inc.:  POSIX is no longer a trademark.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee.  They published the 1003.1 "POSIX" Trial Use
Standard in April 1986.  According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95, with bulk purchasing discounts
available.  Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:

        IEEE Computer Society
        P.O. Box 80452
        Worldway Postal Center
        Los Angeles, Ca. 90080

Include a check for $19.95 + $4 for shipping and handling.  For UPS
shipping, add another $4.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period such
as a year.  The current target for a Full Use Standard is Summer 1988.
Initial balloting is completed, and ballot resolution is in progress:
it's too late to ballot if you haven't already.


IEEE has brought the 1003.1 effort brought into the International
Organization for Standardization (ISO) arena.  IEEE 1003.1 Draft 12
is also a ``Draft Proposed International Standard (ISO DP)'' under
SC22 WG15.  The convenor is Jim Isaak:  see below for his address.
There is a U.S. Technical Advisory Group (TAG) to ISO SC22 WG15:
the chair is Donn Terry of HP.

The National Bureau of Standards is producing a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1.  It will probably
be available before the Full Use Standard, and may reflect Draft 12,
rather than the final 1003.1 standard.  For information, contact:

        Roger Martin
        National Bureau of Standards
        Building 225
        Room B266
        Gaithersburg, MD  20899
        [phone]

NBS is also producing a FIPS based on IEEE 1003.2, probably from
the draft made by 1003.2 at their March meeting.


Machine readable copies of the IEEE 1003.1 Trial Use Standard are not
and will not be available.  The same applies to copies of later drafts.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Tel.: [phone]
        Fax.: [phone]
        decvax!isaak
        [e-mail]
        Digital Equipment
        ZK03-3/Y25
        110 Spit Brook Rd.
        Nashua, NH  03062-2698

Sufficiently interested parties may join the working group.

The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                co-chairs
1003.0    POSIX Guide            Al Hankinson (NBS), Kevin Lewis (DEC)
1003.1    Systems Interface        Jim Isaak (DEC), Donn Terry (HP)
1003.2    Shell and Tools Interface    Hal Jespersen (UniSoft), Don Cragun (Sun)
1003.3    Verification and Testing     Roger Martin (NBS), Carol Raye (AT&T)
1003.4    Real Time             Bill Corwin (Intel)
1003.5    Ada Binding for POSIX        Terry Fong (USArmy), Stowe Boyd(Compass)
1003.6    Security            Dennis Steinauer (NBS), Ron Elliot (IBM)

Inquiries regarding any of the subcommittees should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are:

1988 March 14-18    Ritz-Carlton Hotel, Washington, DC
1988 June 20-24        IEEE 1003.6 at USENIX, in San Francisco, CA
1988 July 11-15        Colorado Springs, CO
1988 October 20-21    ISO SC22 Advisory Group & WG15 - Tokyo, Japan
1988 October 24-28    Maui, Hawaii

1989 January        Ft. Lauderdale, FL
1989 April        Minneapolis-St. Paul, MN
1989 June        Monterey, CA
1989 October        Brussels (or Amsterdam) (Thought: EC host)
1990 January        New Orleans, LA

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    utilities for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about clarifying
the scope of the 1003.2 standard in regard to its relationship with
1003.1.  The Working Group is attempting to produce a standard that
will assume the structure and philosophy of a POSIX system is
available, but it will not require a fully conforming implementation as
a base.  For example, it should be feasible to eventually produce a
1003.2 interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and utilities
didn't need them).  However, the proposed standard will *not* be
unnecessarily watered down simply to allow non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Mike Lambert from X/OPEN.
The two from USENIX and /usr/group are also representatives to the U.S.
TAG to ISO SC22 WG15.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
An article related to this one appeared in the September/October 1986
;login: (The USENIX Association Newsletter).  I'm also currently on the
USENIX Board of Directors.  Comments, suggestions, etc., may be sent to

        John S. Quarterman
        Texas Internet Consulting
        701 Brazos, Suite 500
        Austin TX 78701-3243
        [phone]
        uunet!usenix!jsq
        [e-mail]

For comp.std.unix:
Comments:    uunet!std-unix-request [e-mail]
Submissions:    uunet!std-unix        [e-mail]

The November/December 1987 issue of CommUNIXations (the /usr/group magazine)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in June 1987.

If you are interested in starting another /usr/group working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above.

/usr/group Working Group on Distributed File System:
    Art Sabsevitz            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6248            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    John Wu                Laurie Goudie
    Charles River Data Systems    Santa Cruz Operation
    983 Concord St.,        400 Encinal
    Framingham, MA 01701        Santa Cruz, CA 95060
    617-626-1000            408-458-1422

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

/usr/group Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]


/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail]


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

The current document may be ordered from

        Global Engineering Documents
        2805 McGaw
        Irvine, CA 92714
        USA
        [phone]
        [phone]

Ask for the X3.159 draft standard.  The price is $65.


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        Tel: [phone]
        Fax: [phone]

/usr/group also publishes an eight page document, ``Your Guide to POSIX,''
explaining what IEEE 1003 is, and a nineteen page document, ``POSIX Explored,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations.  Contact /usr/group at the above address
for details.


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (at time of publication, Bull, DEC, Ericsson, Hewlett-Packard,
ICL, NIXDORF, Olivetti, Philips, Siemens and Unisys and subsequently
augmented by AT&T) who have produced a document intended to promote
the writing of portable applications.  They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.

Comments, suggestions, error reports, etc., for Issue 2 of the Green Book
may be mailed directly to:

        [e-mail]
        uunet!mcvax!inset!xopen!xpg2

Information about X/OPEN can be requested from:

        Mike Lambert
        Technical Director
        X/OPEN Ltd
        c/o ICL BRA01
        Lovelace Road
        Bracknell
        Berkshire
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:

        Howard Press
        c/o USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710

        415-528-8649
        {ucbvax,decvax}!usenix!office

4.3BSD User's Manual Set (3 volumes)        $25.00
    User's Reference Manual
    User's Supplementary Documents
    Master Index

4.3BSD Programmer's Manual Set (3 volumes)    $25.00
    Programmer's Reference Maual
    Programmer's Supplementary Documents, Volume 1
    Programmer's Supplementary Documents, Volume 2

4.3BSD System Manager's Manual (1 volume)    $10.00

Unfortunately, there are some license restrictions.
Contact the USENIX office for details.

Volume-Number: Volume 13, Number 20

From uucp  Sun Mar 13 23:16:44 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA02636; Sun, 13 Mar 88 23:16:44 EST
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Expires: 15 Apr 88 04:19:38 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Mar 88 03:52:53 GMT
Apparently-To: std-unix-archive
Status: O

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.
I'm cross-posting it to comp.org.usenix and comp.unix.questions
because there might be interest there.  There is also a lengthy article
on access to UNIX-related standards, but that's only in comp.std.unix.

Corrections and additions to this article are solicited.
Recent additions:  ADUS, AMIX.  IX Magazine is now
Multi-User Computing Magazine.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG, AMIX,
        DECUS UNIX SIG, Sun User Group, Apollo DOMAIN Users' Society
newsletters:    ;login:, /usr/digest, EUUGN, AUUGN, NUZ
journal:    Computing Systems
magazines:    CommUNIXations, UNIX REVIEW, UNIX/WORLD,
        Multi-User Computing Magazine, UNIX Systems, UNIX Magazine

Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.

UNIX is a Registered Trademark of AT&T.


USENIX is ``The Professional and Technical UNIX(R) Association.''

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        U.S.A.
        [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:

    Jun 20-24 1988    Hilton Hotel, San Francisco, CA
    Jan 31-Feb 3 1989 Town & Country Inn, San Diego, CA
    Jun 12-16 1989    Hyatt Regency, Baltimore, MD
    Jan 23-26 1990    Washington, DC
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA
    Jan 22-25 1991    Dallas
    Jun 10-14 1991    Opryland, Nashville

They also sponsor workshops, such as
    May 12-13 1988    Omni Shoreham Hotel, Washington, DC
        Fifth Workshop on Real-Time Software and Operating Systems
        IEEE Computer Society and USENIX Association
    Aug 29-30 1988    UNIX Security, Portland, OR
    Sep 26-27 1988    UNIX & Supercomputing, Pittsburgh, PA
    Oct 17-20 1988    C++ Conference (tentative), Denver, CO
    Nov 17-18 1988    Large Installation System Administration II, Monterey,CA

Proceedings for all conferences and workshops are available at
the door and by mail later.

USENIX publishes ``;login:  The USENIX Association Newsletter''
bimonthly.  It is sent free of charge to all their members and
includes technical papers.  There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.

In 1988, USENIX will start publishing a new refereed quarterly
technical journal, ``Computing Systems:  The Journal of the USENIX
Association,'' in cooperation with University of California Press.

They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership.  They distribute tapes of contributed software and are
pursuing expanding that activity.

There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.


/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        U.S.A.
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.

Proceedings for all conferences are available at the shows and later
by mail.

/usr/group publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.

/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group.  This newsletter covers
product announcements and industry projections, and is sent biweekly
to General members of /usr/group and to non-member subscribers.

/usr/group has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Technical Committee
on areas that P1003 has not yet addressed.  They have recently produced
an executive summary, ``Your Guide to POSIX,'' and a technical overview
``POSIX Explored,'' and funded production of a draft of a ``Rationale and
Notes'' appendix for IEEE 1003.1.


EUUG is the European UNIX systems Users Group.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        Telephone [phone]
        Telefax [phone]
        uunet!mcvax!inset!euug
        [e-mail]

They have a newsletter, EUUGN, and hold two conferences a year:
    11-15 April 1988, London, England
    3-7 October 1988, Lisbon, Portugal


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds at least one conference a year, usually in the spring
(August or September).  The next one will be in Melbourne on 13-15
September 1988, will be the first three day meeting, will have a larger
equipment exhibition than any before, and will be professionally
organized for the first time.

They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.


The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
and publishes a newsletter, ``NUZ.''

        New Zealand UNIX Systems User Group
        P.O. Box 585
        Hamilton
        New Zealand
        [phone]

The next and fifth annual meeting is the New Zealand UNIX Systems User Group
(NZUSUGI) 1988 Conference, June 9-11 1988, in Wellington, New Zealand.

If you wish to present a paper, acceptance of which entitles you to a free
conference registration, please contact the local speakers organiser,
Dr Dick Cooper, ADATA, PO Box 2555, Christchurch, New Zealand,
[e-mail]   or ...uunet!vuwcomp!cantuar!dick

If you would just like to attend, please respond to Ray Brownrigg, including
a postal address for the delivery of further information as it becomes
available.  Registration forms are expected to be available in February.

        UUCP: {utai!calgary,uunet}!vuwcomp!dsiramd!ray
        ACSnet:    [e-mail][@munnari]
        Ray Brownrigg
        Applied Maths Div, DSIR
        PO Box 1335
        Wellington
        New Zealand


The Korean UNIX User Group (KUUG) has a software distribution service
and a newsletter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Chungnam 300-32
        Republic of Korea
        [phone]


The Japan UNIX Society has two meetings a year, and a newsletter.

        Japan UNIX Society
        #505 Towa-Hanzomon Corp. Bldg.
        2-12 Hayabusa-cho
        Chiyoda-ku, Tokyo 102
        Japan
        [phone]


AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli Processing
Association (IPA). AMIX has a yearly conference (next one on 4-6 July 1988)
and a yearly workshop (last one was in November).

        AMIX, c/o IPA
        P.O. Box 919
        Ramat-Gan
        Israel, 52109
        Tel: [phone],715772
        [e-mail]
        [e-mail]


There are similar groups in other parts of the world.  If such a group
wishes to be included in later versions of this access list, they
should please send me information.

There is a partial list of national organizations in the November/December
1987 CommUNIXations.



DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held twice a year.

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        U.S.A.
        [phone]

See also the USENET newsgroup comp.org.decus.


The Sun User Group (SUG) is an international organization that promotes
communication among Sun users, OEMs, third party vendors, and Sun
Microsystems, Inc.  SUG sponsors conferences, collects and distributes
software, produces the README newsletter and T-shirts, sponsors local
user groups, and communicates members' problems to Sun employees and
management.

    Sun Microsystems User Group, Inc.
    2550 Garcia Avenue
    Mountain View, CA  94043
    U.S.A.
    [phone]
    [e-mail]
    sun!users

They have not set a date/location for the 1988 conference yet, but are
actively looking for a hotel (with good pricing and lots of room).
They've narrowed it down to several locations - Miami/Tampa Florida,
Houston/Dallas Texas, and New Orleans LA.  The date will probably be
very early December, 1988.


ADUS is the Apollo DOMAIN Users' Society:

    Apollo DOMAIN Users' Society
    c/o Andrea Woloski, ADUS Coordinator
    Apollo Computer Inc.
    330 Billerica Rd.
    Chelmsford, MA 01824
    [phone], x4448


The main general circulation (more than 10,000 copies per issue) magazines
about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    U.S.A.                U.S.A.
    [phone]            [phone]


    Multi-User Computing magazine    UNIX Systems
    Storyplace Ltd.            Eaglehead Publishing Ltd.
    42 Colebrook Row        Maybury Road
    London  N1 8AF            Woking, Surrey GU21 5HX
    England                England
    [phone]            [phone]

    UNIX Magazine
    Jouji Ohkubo
    c/o ASCII Corp.
    [e-mail]
    [phone]
    fax: [phone]
    telex: 242-6875 ASCIIJ

In addition:

    Computing Systems        CommUNIXations
    USENIX Association        /usr/group
    P.O. Box 2299            4655 Old Ironsides Drive, Suite 200
    Berkeley, CA 94710        Santa Clara, California 95054
    U.S.A.                U.S.A.
    [phone]            [phone]

Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters.  The following
information about bookstores was taken from the same issue.  In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.

    Computer Literacy Bookshop    UNIX Book Service
    2590 No. First St.        35 Bermuda Terrace
    San Jose, CA 95131        Cambridge, CB4 3LD
    U.S.A.                England
    [phone]        [phone]

    Cucumber Bookshop        Jim Joyce's UNIX Book Store
    5611 Kraft Ave.            47 Potomac St.
    Rockville, MD 20852        San Francisco, CA 94117
    U.S.A.                U.S.A.
    [phone]            [phone]

Volume-Number: Volume 13, Number 21

From uucp  Sun Mar 13 23:17:51 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA02704; Sun, 13 Mar 88 23:17:51 EST
From: [e-mail] (comp.std.unix Moderator, John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: calendar of UNIX-related events
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (comp.std.unix Moderator, John S. Quarterman)
Date: 14 Mar 88 03:58:06 GMT
Apparently-To: std-unix-archive
Status: O

Here is a combined calendar of planned conferences, workshops, or
standards meetings by various organizations.  I compiled it for
my own use and thought it might be of some public interest.  Most
of this information came from the various conference organizers,
although some was taken from ;login: (USENIX), 13, 1, Jan/Feb
1988 and CommUNIXations (/usr/group), VII, 6, Nov/Dec 1987.

Abbreviations: U for UNIX, W for Workshop, C for Center.  The
sponsors of the USENIX, EUUG, and AUUG conferences are the
organizations of the same name, and the sponsor of UniForum is
/usr/group.  Dates and places for IEEE 1003 after Oct 1988 are
tentative, and also for the 1992 UniForum.

Changes since last posting: Dates for July and October IEEE 1003
and ISO WG15 meetings.

year mon days       conference name      (sponsor,) (hotel,) location

1988 Mar 14-18      IEEE 1003            Ritz-Carlton, Washington, DC
1988 Apr 11-15      EUUG                 QE II Conference C, London
1988 May 3-5        U Exposition         AFUU, Palais des Congress, Paris
1988 May 12-13      Real-Time W          USENIX/IEEE, Omni Shoreham, Washington
1988 May 17-19      UNIX 88/etc.         /usr/group/cdn, Convention C, Toronto
1988 Jun 7-9        COMUNIX              /usr/group/UK, Alexandra Palace, London
1988 Jun 9-11       NZSUGI               Wellington, New Zealand
1988 Jun 20-24      USENIX               Hilton, San Francisco, CA
1988 Jun 20-24      IEEE 1003.6          at USENIX, in San Francisco, CA

1988 Jul            U Symposium          JUS, Tokyo, Japan
1988 Jul 4-6        AMIX                 Israel
1988 Jul 11-15      IEEE 1003            Colorado Springs, CO
1988 Aug 2-4        UniForum/DC          Washington Hilton, Washington, DC
1988 Aug 29-30      U Security W         USENIX, Portland, OR
1988 Sep 13-15      AUUG                 Melbourne, Australia
1988 Sep 26-27      U&Supercomputing W   USENIX, Pittsburgh, PA
1988 Oct 3-7        EUUG                 Lisbon, Portugal
1988 Oct 17-21      C++ Conference       USENIX, Denver, CO
1988 Oct 20-21      ISO SC22 & WG15      Tokyo, Japan
1988 Oct 24-28      IEEE 1003            Maui, Hawaii
1988 Oct            UNIX Expo            New York, NY
1988 Nov 17-18      Large Installation   Syst. Adm. W II, USENIX, Monterey, CA
1988 Nov            U Symposium          JUS, Osaka, Japan
1988 Dec            Sun User Group       southern U.S.A.
1988 Dec            UNIX Fair            JUS, Tokyo, Japan

1989 Jan            IEEE 1003            Ft. Lauderdale, FL
1989 Jan 31-Feb 3   USENIX               Town and Country, San Diego, CA
1989 Feb 28-Mar 3   UniForum             Moscone Center, San Francisco, CA
1989 Apr            IEEE 1003            Minneapolis-St. Paul, MN
1989 Apr            EUUG                 Brussels, Belgium
1989 Jun 12-16      USENIX               Hyatt Regency, Baltimore, MD
1989 Jun            IEEE 1003            Monterey, CA
1989 Oct            IEEE 1003            Brussels (or Amsterdam)
1989 Oct            UNIX Expo            New York, NY

1990 Jan 23-26      USENIX               Washington, DC
1990 Jan 23-26      UniForum             Washington Hilton, Washington, DC
1990 Jan            IEEE 1003            New Orleans, LA
1990 Jun 11-15      USENIX               Marriott, Anaheim, CA

1991 Jan 22-25      USENIX               Dallas, TX
1991 Jan 22-25      UniForum             Infomart, Dallas, TX
1991 Jun 10-14      USENIX               Opryland, Nashville, TN

1992 Jan 21-24      UniForum (?)         Moscone Center, San Francisco CA

Volume-Number: Volume 13, Number 22

From uucp  Wed Mar 23 00:08:39 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA15842; Wed, 23 Mar 88 00:08:39 EST
From: Georges Grinstein <[e-mail]>
Newsgroups: comp.std.unix
Subject: X3H3.6, the Window Management System Standard Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Georges Grinstein <[e-mail]>
Date: 16 Mar 88 05:53:19 GMT
Apparently-To: std-unix-archive
Status: O

From: Georges Grinstein <[e-mail]>

X3H3.6 has had a name change as can be seen from the subject line.
My address has changed and since many requests for information have managed
to find themselves to me, I assume many more have not.  Here is the
corrected address:

     [e-mail]

Volume-Number: Volume 13, Number 23

From uucp  Wed Mar 23 00:10:38 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA16068; Wed, 23 Mar 88 00:10:38 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Machine Readable ANSI C Std?
Message-Id: <[e-mail]>
Reply-To: Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>
Date: 15 Mar 88 20:05:53 GMT
Apparently-To: std-unix-archive
Status: O

From: Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>

Is there a machine readable copy of the ANSI C standard available?
 "   "   "   "  available via anonymous ftp?
-russ

[ I don't think so.  Does anyone know for sure?  -mod ]

Volume-Number: Volume 13, Number 24

From uucp  Wed Mar 23 00:11:41 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA16184; Wed, 23 Mar 88 00:11:41 EST
From: Cees Bol <[e-mail]>
Newsgroups: comp.std.unix
Subject: manuals
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: uva!cees (Cees Bol)
Organization: Faculteit Wiskunde & Informatica, Universiteit van Amsterdam
Date: 16 Mar 88 16:16:07 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Cees Bol)

    Hello world,

    I read on the news that USENIX publishes an edition of
    the 4.3BSD manuals. What kind of edition is this?
    And are these manuals available for USENIX members,EUUG
    members, students etc...?

[ All USENIX members.  I'm not sure whether the various EUUG/USENIX
reciprocal arrangements include the manuals.  Check with the EUUG or
USENIX offices. -jsq ]

    Most important thing is in what "format" are the manuals?
    Is this A4 format (about 8*11 inch), single sided in big
    ringbinders or in  handy paperback format which are easy
    to carry with you.

[ Double-sided in book-size (about 7.5*9 inch) paperbacks with plastic
binders that allow opening flat; the binders are color-coded for easy
recognition.  All papers have been retypeset and there is a complete
index in a separate volume.  -jsq ]

    You will understand that I am looking for such an edition.
    I have seen such an edition in Holland but they are not
    available anymore. All BSD manuals seperated in eight little
    books which are easy carry to your work, school, bar etc....
    That's what I like. And for a good price of course.

[ Apparently not the same, but a similar idea.  -jsq ]

    Yours faithfully,

    Cees Bol
    Nieuwe Achtergracht 166
    1018 WV Amsterdam
    Holland

    e-mail: ...uunet!mcvax!uva!cees
            [e-mail]

Volume-Number: Volume 13, Number 25

From uucp  Wed Mar 23 00:12:49 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA16320; Wed, 23 Mar 88 00:12:49 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: calendar of UNIX-related events
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!decuac.dec.com!hadron!avolio (Frederick M. Avolio)
Organization: DEC Software Services
Date: 14 Mar 88 18:15:07 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!decuac.dec.com!hadron!avolio (Frederick M. Avolio)

Perhaps you could start including DECUS events if supplied? (I see
SUN User Group is listed.)  I understand that DECUS is more than Unix,
(it is a feature... I mean what else does Sun run ?:-) ) but the
UNISIG of DECUS US is getting pretty big and the seminars, etc. are
also very good.  I have Cc'ed the current UNISIG chair -- Kurt Reisler
-- on this so that perhaps he can supply you with the conference dates
if interested.

Thanks

Fred

[ I've been listing UNISIG for quite a while in the article on UNIX
groups.  I used to list DECUS conferences there, too, but since I don't
usually go to them I've not been willing to spend time to track down
their schedules.  If somebody wants to send me that information, I'll
be glad to post it, both in the groups and calendar articles.

Similarly, the Apollo Domain Users' Group is now listed in the groups
article but not in the calendar, while Sun Users' Group is in both:
someone sent me the date for the next SUG, but nobody has for ADUS.

In other words, these informational compendia are real low-budget
operations, folks.  I post what I have at hand when posting time
(more or less every month to three months) comes.  -mod ]

Volume-Number: Volume 13, Number 26

From uucp  Wed Mar 23 15:14:42 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA12210; Wed, 23 Mar 88 15:14:42 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Safe to use *_t typedefs?
Keywords: ANSI C, typedef, *_t types
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 20 Mar 88 02:12:54 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!brl-smoke.ARPA!gwyn (Doug Gwyn )

In article <[e-mail]> [e-mail] (59463-MH Cox) writes:
>The proposed ANSI standard C has produced
>a lot of new data types:  size_t, time_t, etc.  I was starting to
>adopt their "_t" convention for my own data types, when
>I suddenly realized (excuse me, if this is obvious to everyone
>else :-) I might be headed for a type clash with a future
>ANSI C typedef.  Did the ANSI C committe intend to reserve all
>typedefs of the form *_t for their own use?  Should I
>avoid typedefs of this form in my applications?

The following is my own opinion and should not be taken
as an official X3J11 response:

Only those portions of the name space explicitly identified
in the ANSI C standard as reserved for implementation use
are unsafe for portable applications to use.  *_t (where *
starts with a alphabetic character) is not reserved except
for the specific types such as time_t named in the standard.

However, you may have a problem if you define your own *_t
types in a POSIX environment, since POSIX introduces some more
types.  What IEEE Std 1003.1 should say, but as of Draft 12
as modified so far during the balloting process does not say,
is that inclusion of <sys/types.h> may define additional types
(other than those explicitly named in the POSIX standard) with
names of the form *_t.  What the revised draft currently says
is that <sys/types.h> may define additional types having any
names whatsoever; this is clearly not in line with the
professed goal of "promoting portable applications".  A
similar botch is found in IEEE Std 1003.1 <signal.h>, which
should only allow (besides more SIG* names) additional macros
having names of the form SA_*, but currently also allows any
names whatsoever to be usurped by the implementation.

These problems with 1003.1 are in addition to the generic one
of a contradiction between the requirements of ANSI C and of
POSIX for what names the headers that they share can define.
The X3J11 committee sent 1003.1 a letter explaining the
problem and suggesting a simple solution (that in practice
would usually be met by the application programmer arranging
for <unistd.h> to be included before the headers in question).
However, so far 1003.1 has come up with a different "solution"
that merely avoids solving the problem.  My guess is that they
don't understand the issue; or possibly they have yielded to
pressure to bless the existing messy situation in the UNIX
world as "already POSIX conformant", in which case one wonders
what the point of the standard is.  (If you say that it is
becoming mostly a marketing ploy rather than an aid to
programmers, I might not disagree.)

Since it appears that 75% of the balloters have now voted yea
on draft 1003.1, we are in danger of getting a standard that
does not solve these fundamental portability problems.  I have
been urging procurement specifications that require more than
1003.1 conformance, for example ANSI C and SVID compliance,
with an order of precedence specified for cases where the
several specifications conflict (with ANSI C first, since it
is more basic and universal than the other specs).  This seems
to be the only safe course given the weaknesses and
incompleteness of 1003.1 as it now stands.  (It has gotten
better than it was a year ago, though, mostly under NBS
influence.)

Volume-Number: Volume 13, Number 27

From uucp  Wed Mar 23 15:47:03 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA15239; Wed, 23 Mar 88 15:47:03 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Safe to use *_t typedefs?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Date: 23 Mar 88 19:38:24 GMT
Apparently-To: std-unix-archive
Status: O

Doug Gwyn writes:
>Since it appears that 75% of the balloters have now voted yea
>on draft 1003.1, we are in danger of getting a standard that
>does not solve these fundamental portability problems.

Just to clarify somewhat the rather confusing IEEE balloting
procedure currently going on for 1003.1:

1003.1 is not a standard yet.  75% of the balloting quorum returned
ballots during the initial thirty day period, and 75% of those were
positive, allowing a ballot resolution period, which was set at ten
days.  There are claims that 77% positive ballots were received during
that resolution period.  But the period was too short for many people
to respond, and there were other problems (all three of Institutional
Representatives, from USENIX, /usr/group, and X/OPEN, as well as
others, sent letters to the IEEE Standards Board pointing this out).
There will be another resolution period, probably in April.

At this point if you haven't already balloted, you can't.  But there's
still some time for improvements in 1003.1, and some problems may have
been resolved at the 1003 meeting last week in D.C.

The IEEE Standards Review Committee accepted 1003.1 as a conditional
standard at their last meeting, a week or so ago.  I don't know what
that means, but I do know it does not mean that 1003.1 is a standard yet.

Volume-Number: Volume 13, Number 28

From uucp  Wed Mar 23 22:19:08 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09227; Wed, 23 Mar 88 22:19:08 EST
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Machine Readable ANSI C Std?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Mar 88 20:12:06 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail]

    Is there a machine readable copy of the ANSI C standard available?
     "   "   "   "  available via anonymous ftp?
    -russ

    [ I don't think so.  Does anyone know for sure?  -mod ]

    Volume-Number: Volume 13, Number 24

Alas, no.  ANSI makes its money from publishing standards.  If there was
a machine readable copy of the standard around for anonymous ftp, then many
people would get a hold of it that way, rather than buy it from ANSI.
Therefore, we can not distribute it electronically.  (We do, of course,
keep it on a computer for editing purposes, but it isn't available to
the public.)

My own personal opinion is that standards ought to be developed by some
sort of subsidized, not-for-profit organization, and be available at media
cost.  (For all I know ANSI may BE "not-for-profit".  That still doesn't
mean they'll give away the standards they create.)

If you want a paper copy of the current Draft, write to the address below.
(This came from a previous std-unix posting.)

                Global Press
                2625 Hickory St.
                P.O. Box 2504
                Santa Anna, CA 92707-3783
                U.S.A.
                800-854-7179
                [phone] (from outside the U.S., ask for extension 245.)
                TELEX 692 373

[ They moved.  More currently, they appear to be:

        Global Engineering Documents
        2805 McGaw
        Irvine, CA 92714
        USA
        [phone]
        [phone]

-mod ]

Ask for the X3.159 draft standard.  The price is $65.


Jim Williams
X3J11, The ANSI C Committee

 ------------------------------------------------------------
There is no 'd' in "kluge"!  It rhymes with "deluge", not "sludge".

James W. Williams            [e-mail]
Systems Administrator, Code 5505
Information Technology Division
Naval Research Laboratory        [phone]
Washington, DC 20375
 ------------------------------------------------------------

Volume-Number: Volume 13, Number 29

From uucp  Wed Mar 23 22:20:10 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09281; Wed, 23 Mar 88 22:20:10 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Machine Readable ANSI C Std?
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 23 Mar 88 21:59:56 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!brl-smoke.ARPA!gwyn (Doug Gwyn )

In article <[e-mail]> Russ Nelson <uunet!sun.soe.clarkson.edu!nelson> writes:
>Is there a machine readable copy of the ANSI C standard available?
> "   "   "   "  available via anonymous ftp?

The X3J11 draft redactor has his own machine-readable (troff -mm)
copy of the draft standard, but previous requests for copies of it
have been answered with the observation that it would be an
additional burden for someone (e.g. the redactor) and that resources
have not been made available to support this.  Occasionally it is
suggested that it would be nice to do so, and we agree it might be
"nice", but it hasn't been done.  I would say it seems rather
unlikely at this point.

One argument against the idea has been that it would make it easy
for someone to crank out copies of a document that looked like the
official standard but that had deviations from it, which is deemed
undesirable.

Volume-Number: Volume 13, Number 30

From uucp  Wed Mar 23 22:25:22 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA10041; Wed, 23 Mar 88 22:25:22 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Dominic Dunlop <[e-mail]>
Organization: Sphinx Ltd., Maidenhead, England
Date: 16 Mar 88 13:33:38 GMT
Apparently-To: std-unix-archive
Status: O

From: Dominic Dunlop <uunet!mcvax!sphinx.co.uk!domo>

Hi John,

Don't know how far you want to go on UNIX-related periodicals.

[ Me neither.  Does anyone have any comments as to which of these
they would like to see in the usual UNIX User Groups and Publications
article?  If so, please mail to std-unix-request.  I'll summarize later,
probably by incorporating some of the listings from below into the article.
-mod ]

Here are six more possibles:

3B/Journal                      ``A publication written by 3B computer
Owens-Laing Publications Inc      users for the support of 3B computer
PO Box 2409                       users.''  Covers AT&T UNIX boxes.
Redmond WA 98073-2409
                                  Bimonthly
[phone]                   $25/yr (US); $35/yr (Can); $82/yr (air)
attmail!alpha!jou

AT&T Technical Journal            Not much to be said.  While few issues
AT&T Bell Laboratories            are devoted to UNIX, most turn out to
Circulation Dept.                 mention its applications.
Room 1K-424
101 J F Kennedy Parkway           Bimonthly
Short Hills NJ 07078              $40/yr (US); $50/yr (overseas)

[phone]

Byte                              Concentrates mainly on personal
McGraw-Hill Inc.                  computer, but covers low end of UNIX
Phoenix Mill Lane                 market in some depth.
Peterborough NH 03458
                                  Monthly
[phone]                   $22/yr (US); $25/yr(Mex,Can); $37/yr
                                  (surface); $69/yr (air,Europe)

The C Users Journal             ``A service of the C Users Group.''
R&D Publications Inc              Mainly DOS-oriented; some UNIX.
PO Box 97
McPherson KS 67460                Eight issues per year
                                  $20/yr (US/Mex/Can); $30/yr (overseas)
[phone]

Microsoft Systems Journal         Concentrates mainly on MS-DOS and
Microsoft Corp                    OS/2; some references to Xenix
666 Third Avenue                  creep in.
New York NY 10017
                                  Bimonthly (actually very sporadic)
800 533-6625                      $50/yr (US); $65/yr (Mex,Can);
800 533-3157 (Ohio)             ``International rates on request''
Overseas: contact local Microsoft office

Unique                          ``The UNIX System Information Source.''
Infopro Systems                   High-quality industry newsletter.
PO Box 220                        Emphasis on marketing implications of
Rescue CA 95672                   technical developments.

[phone]                   Monthly
                                  $79/yr (US,overseas); $99/yr (air)

Use it as you see fit.
--
Dominic Dunlop
[e-mail]  [e-mail]

Volume-Number: Volume 13, Number 31

From uucp  Thu Mar 24 10:16:19 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA00739; Thu, 24 Mar 88 10:16:19 EST
From: Clyde T. Poole <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Frederick M. Avolio's Request
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Clyde T. Poole)
Date: 23 Mar 88 16:18:46 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Clyde T. Poole)

John,

Here are the dates for the next two DECUS U.S. Symposia:

    May 16-20, 1988        Cincinnati, Ohio
    Oct 17-21, 1988        Anaheim, California

I will try to keep you posted about the dates of future Symposia.

ctp

Volume-Number: Volume 13, Number 32

From uucp  Fri Mar 25 19:06:49 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA26964; Fri, 25 Mar 88 19:06:49 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Machine Readable ANSI C Std?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: uunet!crdos1!davidsen (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Date: 25 Mar 88 16:24:32 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!crdos1!davidsen (William E. Davidsen Jr)

In article <[e-mail]> [e-mail] (Doug Gwyn (VLD/VMB) <uunet!brl.arpa!gwyn>) writes:
| [...]
| One argument against the idea has been that it would make it easy
| for someone to crank out copies of a document that looked like the
| official standard but that had deviations from it, which is deemed
| undesirable.

Of course it would also (a) cut the money that Global Press makes
selling the standard ($1 per page????) and would allow sites to keep it
online to improve use for it.  I would think CBEMA would want to sell
site licenses for the document.

[ What does ``to improve use for it'' mean?  -mod ]
--
    bill davidsen        ([e-mail])
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

Volume-Number: Volume 13, Number 33

From uucp  Fri Mar 25 19:09:00 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA27253; Fri, 25 Mar 88 19:09:00 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: UNIX standard
Summary: Will UNIX become hardware dependent?
Keywords: UNIX SPARC
Message-Id: <[e-mail]>
Reply-To: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)
Organization: Eaton Inc. IMSD, Westlake Village, CA
Date: 25 Mar 88 18:45:25 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)

   We recently had some SUN reps come to give a presentation about SPARC.
   They were strongly suggesting that due to their relationship with AT&T
   (that is AT&T will soon sell SPARC) it will soon be the case that if you
   are not a SPARC machine you will not *really* be UNIX compatible. They
   were talking about a coming binary standard, so that you could buy a
   program written for UNIX and know that it would run on your UNIX machine
   the same way you know that PC software will always run on your Intel/PC.
   This binary standard would assumably be based on the SPARC instruction
   set.
   Is this stuff true or is it just marketing hype? Is UNIX really going to
   become hardware dependent? What about all of us out here with our 680x0
   or 80x86 or VAXen or whatever? Are we going to be second-class UNIX users,
   unable to run the bulk of UNIX software? Can anybody out there clarify
   this?

   -----------------------------------------------------------------------
   Any opinion expressed above is mine only. {ihnp4 or voder}!wlbr!etn-rad!jru

Volume-Number: Volume 13, Number 34

From uucp  Sun Mar 27 13:03:21 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA27149; Sun, 27 Mar 88 13:03:21 EST
From: Charles Hedrick <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX standard
Keywords: UNIX SPARC
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Charles Hedrick)
Organization: Rutgers Univ., New Brunswick, N.J.
Date: 27 Mar 88 05:57:48 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Charles Hedrick)

uunet!wlbr.eaton.com!etn-rad!jru (John Unekis) says some Sun sales
types claimed that because of the ABI (binary standard), if your
machine isn't based on SPARC (the Sun RISC chip), it wouldn't *really*
be Unix compatible.  He asks whether this is just hype.

This issue has been discussed in the trade press a lot.  A number of
vendors are quite upset at the Sun/ATT cooperative deal for precisely
this reason.  They want Unix to continue to be open.  ATT has been
reassuring people that Unix will indeed continue to be open.  ATT is
helping create binary standards for SPARC and 386.  Other vendors with
serious interest in Unix are sponsoring similar standards for their
chips, e.g. Motorola for the 680x0.

The other major issue is whether other vendors will get advance copies
of new releases soon enough that they can come out with their own
ports, and not have Sun and ATT always be a year ahead of them.  ATT is
now saying that they will continue to do this, and that their own field
test and other overheads are long enough that other vendors should be
able to come out with releases at roughly the same time as the ones
that ATT produces.

It will be interesting to see how things develop in this area.  I'm
sure both ATT and Sun have toyed from time to time with the idea of
closing Unix (whatever that means), but I don't see any way that that
could really happen.

[ Please pardon the paragraphing, Charles:  I couldn't read it as
one big block of text.  -mod ]

Volume-Number: Volume 13, Number 35

From uucp  Sun Mar 27 13:05:18 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA27182; Sun, 27 Mar 88 13:05:18 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Bad Luck with this one... (was Re: Access to UNIX ... Publications)
Summary: This one isn't good!!
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: uunet!talcott.harvard.edu!icus!lenny (Lenny Tropiano)
Organization: ICUS Computer Group, Islip, NY
Date: 27 Mar 88 05:58:32 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!talcott.harvard.edu!icus!lenny (Lenny Tropiano)

In article <[e-mail]> Dominic Dunlop <[e-mail]> writes:
|>From: Dominic Dunlop <uunet!mcvax!sphinx.co.uk!domo>
...
|>Here are six more possibles:
|>
|>3B/Journal                      ``A publication written by 3B computer
|>Owens-Laing Publications Inc      users for the support of 3B computer
|>PO Box 2409                       users.''  Covers AT&T UNIX boxes.
|>Redmond WA 98073-2409
|>                                  Bimonthly
|>[phone]                   $25/yr (US); $35/yr (Can); $82/yr (air)
|>attmail!alpha!jou
|>
...

Unfortunately I had bad luck with the 3B/Journal publication!  First of
all from the one issue I did get it wasn't worth the $25.00/yr ($5.00
per issue -- you're paying for the paper they print it on).  I decided
to subscribe to this publication, back last year around April/May 1987.
I paid my $25.00 via Mastercard, and received the first issue in
July (July/August bimonthy issue).  The journal had 30 pages, with 20%
being advertisements.  That didn't bother me all that much, as long
as the rest of it had some content (which in my opinion it didn't).

I didn't receive any publications for 6 months, and then I remembered
about it.  I called them and their number was changed.  After finally
tracking them down, I found out they moved and they were a little
behind on the publications, but the promised me that the Nov/Dec issue
would be coming soon.  I still haven't receive any new issues.  I wrote
attmail!alpha!jou and attmail!alpha!plo (Paul Owens) wrote back.  He
said that he apologized about the delays and the issues should be
coming real soon.  This was back in January.  It's now March.  I just
wrote and CANCELLED my subscription wanting a FULL REFUND of $25.00.
They have no right in holding my money for over a year with just
one issue!!

I don't RECOMMEND this Journal at all.  Be warned.

                            -Lenny


[ The above is, of course, a personal opinion.  -mod ]

---
US MAIL  : Lenny Tropiano, ICUS Computer Group        IIIII  CCC U   U  SSS
           PO Box 1                                     I   C    U   U S
       Islip Terrace, New York  11752               I   C    U   U  SS
PHONE    : [phone] [H] [phone] [W]        I   C    U   U    S
TELEX    : 154232428 [ICUS]                           IIIII  CCC  UUU  SSS
AT&T MAIL: ...attmail!icus!lenny
UUCP     : ...{mtune, ihnp4, boulder, talcott, sbcs, bc-cis}!icus!lenny

Volume-Number: Volume 13, Number 36

From uucp  Sun Mar 27 23:37:10 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA24593; Sun, 27 Mar 88 23:37:10 EST
From: Jim Barton <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX standard
Summary: Not Likely
Keywords: UNIX SPARC
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim Barton)
Organization: Silicon Graphics Inc, Mountain View, CA
Date: 27 Mar 88 21:06:01 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Jim Barton)

In article <[e-mail]>:
> From: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)
>
>    We recently had some SUN reps come to give a presentation about SPARC.
>    They were strongly suggesting that due to their relationship with AT&T
>    (that is AT&T will soon sell SPARC) it will soon be the case that if you
>    are not a SPARC machine you will not *really* be UNIX compatible. They
>    were talking about a coming binary standard, so that you could buy a
>    program written for UNIX and know that it would run on your UNIX machine
>    the same way you know that PC software will always run on your Intel/PC.
>    This binary standard would assumably be based on the SPARC instruction
>    set.
>    Is this stuff true or is it just marketing hype? Is UNIX really going to
>    become hardware dependent? What about all of us out here with our 680x0
>    or 80x86 or VAXen or whatever? Are we going to be second-class UNIX users,
>    unable to run the bulk of UNIX software? Can anybody out there clarify
>    this?
>
>    -----------------------------------------------------------------------
>    Any opinion expressed above is mine only. {ihnp4 or voder}!wlbr!etn-rad!jru
>
> Volume-Number: Volume 13, Number 34

Before one bites too hard on this hype, you should remember that Sun will
soon be selling 80386 based boxes.  How can they sell said systems if
they aren't standard UNIX?  What about all those Sun-3's out there, do they
suddenly become useless to everybody?

You should also check out AT&T's side of the story, which is different
than Sun's.  As far as they are concerned, there will be a binary standard
for UNIX for every type of processor.  Thus, there will be a SPARC ABI,
but it will be just one out of the collection, including 386 ABI
(signed with Microsoft just last year), 68K ABI (signed with Motorola
very recently) and others on the way.

Sun would like to be the IBM of the workstation industry.  Backward technology,
marketing hype, trashing competitors and the like.  AT&T doesn't even claim
that SPARC is state-of-the-art, or best performance anymore either.  Just
that it is standard (Remember, what an "open standard" is by the new rules:
I design something I like, publish barely enough information for somebody
else to >expensively< duplicate it, and proclaim it a standard.  I don't
need your concurrence or opinions, nor do I wan't them.  After all, you
might have a better idea ...).

Finally, think about a sales organization that would send their salepeople
out with such a story.  You are obviously concerned by it, and see the
flaws.  They trash their own current and future sales of 386 and 68K boxes
to scare you into buying SPARC boxes.

Would you buy a computer from these people?

[ Ok, folks:  this is a technical newsgroup, for technical discussions.
It's hard to talk about standards without talking about politics, but
let's try to avoid casting aspersions on companies or people.  -mod ]

-- Jim Barton
Silicon Graphics Computing Systems    "UNIX: Live Free Or Die!"
[e-mail], sgi![e-mail], ...{decwrl,sun}!sgi!jmb
--

Volume-Number: Volume 13, Number 37

From uucp  Mon Mar 28 21:43:39 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA10676; Mon, 28 Mar 88 21:43:39 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: UNIX standard
Keywords: UNIX SPARC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)
Organization: Eaton Inc. IMSD, Westlake Village, CA
Date: 28 Mar 88 18:28:01 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)

In article <[e-mail]>:
>From: [e-mail] (Jim Barton)
>
>In article <[e-mail]>:
>> From: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)
>>
>>    We recently had some SUN reps come to give a presentation about SPARC.
>>    They were strongly suggesting that due to their relationship with AT&T
>>    (that is AT&T will soon sell SPARC) it will soon be the case that if you
>>    are not a SPARC machine you will not *really* be UNIX compatible. They
>
>Finally, think about a sales organization that would send their salepeople
>out with such a story.  You are obviously concerned by it, and see the
.....
  I realized after posting this article that it sounded critical of SUN,
  and might result in some flames in their direction. That was not at all
  my intention. SUN is an excellent company, and thay have always supported
  us well. My question was actually more concerned with the future of UNIX
  as an open standard. Obviously keeping UNIX open is a double edged sword
  for AT&T, they gain great credit as the source of the most widely accepted
  non-hardware dependent OS, but does it really benefit the sales of their
  machines? If AT&T were ever to pick a hardware standard as the basis for
  a product dependent UNIX, the SPARC would be an excellent choice. The
  real question, I suppose, is can an open standard like UNIX really survive
  in today's feircely competitive marketplace?

  -----------------------------------------------------------------------
  Any opinions expressed above are mine only. {ihnp4 or voder}!wlbr!etn-rad!jru

Volume-Number: Volume 13, Number 38

From jsq  Fri Apr  1 14:34:57 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09140; Fri, 1 Apr 88 14:34:57 EST
From: Ghie-Hugh Song  <[e-mail]>
Newsgroups: comp.std.unix
Subject: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ghie-Hugh Song )
Date: 29 Mar 88 03:06:55 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Ghie-Hugh Song )

Hello, everyone,

Have you ever dreamed that TeX were more WYSWYG or that you could type
Greek characters in the text mode directly?  If we had an extended
256 8-bit ASCII character set such as IBM PC's. (See Appendix of
PC DOS Manual), things would be much easier.

  Then why not use WordPerfect or MS Word?  First, all the Greek
characters and the math symbols are not supported by them, unless we
buy extra software and hardware.  In IBM's extended ASCII, there is
no 'Greek tau', 'Greek nu', or inverted Greek capital delta symbol
for partial differential equations. Even the registered trade mark
sign 'R in a circle' does not exist.  Then you might ask why not ChiWriter
or T-cube?  Simply they are not portable!  They are graphics programs.
They are not public-domain.  One of them is really expensive.
So TeX has been thought to be a better choice for technical writers.  But
it's not because it is easy to use but because the text is portable
and sometimes it is more versatile than other PC word processors.   In fact,
without a laser printer or VorTeX and a graphics workstation, TeX is
not so useful as PC word processors.  So something should be 1) ASCII
text files for portability and 2) easy to use.  Then how about having
Greek characters and math symbols in the ASCII character set itself?

   I've got an idea for all of us.  And I wish to write a letter to
the ANSI people about a new 256 8-bit extended ASCII character standard.
But I don't know the ANSI's address.  So if you agree with my idea,
please forward this message to ANSI with your opinion.

   Let's have the Ext-key in our keyboard at the same location as the
'Alt' key in IBM's Enhanced keyboard. (I am using the term 'Ext' to
distinguish it from GNU-Emacs' meta-editing keys.  However, the real name
of the latter half of this extended ASCII set should be
'meta', since they call it in that way in the termcap files.)
Ext-p (F0-hexdec) will give us a printable character Greek-pi,
and Ext-shift-p (D0-hexdec) will give us a printable character
Greek-Pi (captial-pi) directly. IBM's Greek-pi is in E3 in
hexadecimal which matches 'c' (63-Hexdec) among
128 7-bit ASCII codes. So every word processor is different in its way of
producing pi.  It lowers the portability of word-processed texts.

   At the end of this posting, I propose my draft. Please see and
examine it.

   One may oppose this draft because the existing printers might not be used.
We can use those with a mere printer driver software with a translater
software as long as we do not type in the original text any one of the fonts
not supported by the printer.

   I understand that the standardization of 8-bit extended ASCII
is too late.  However I know that once this is implemented on
the new version of UNIX or POSIX, everyone will follow
this slowly.  Now people are gathering to standardize UNIX, POSIX, SVID,
or whatever.  Now is the time to express our opinion to ANSI people.
If we lose this chance we will never have a standard 8-bit ASCII.
If you agree with my idea, write a letter to ANSI, POSIX committee
(IEEE CS/P1003), and the acting System V.4 committee members of
AT&T-Sun-Unisys(?) immediately for their
prompt action.  Unfortunately, I do not know any of those addresses.

  I really do not know whether this effort is made first by me.
Nor do I know whether there exists such extended ASCII made by ANSI.
Since no text-mode terminal has inherent math fonts, I think there is no
such standard so far.

  More than one half of college graduates in the world are either
engineers, scientist, or medical doctors.  They need English with Greek
characters and math fonts to write reports, homeworks, papers. The need
sometimes exceeds that of their own language support.  They need
a knowledge bank that can save some great idea like

          E = h-bar.omega  : Einstein's photoelectric effect,
          E = mc^2         : Einstein's relativistic energy

without backslashes or $'s, and yet portable.

   Thank you for your attention.

                               G. Hugh Song

                               Coordinated Science Lab.
                               Univ. of Illinois at Urbana-Champaign
                               1101 W. Springfield Av.
                               Urbana, IL 61801
                               [e-mail]

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

   Here is my draft of 256 new 8-bit ASCII character set.  I place the
second half of 8-bit characters (128-255) next to the first half of them.

   I am not decisive on what to assign to the following Ext-control keys (80-
hexdec to 9f-hexdec).  There are two options:

1) We can assign new control keys which have become neccessary
   as the computer science evolves.  Some examples are shown below.
   I wish that someone in the field rearrage the assignment and
   complete this, since I do not have enough knowledge and current
   implementation status of i/o utilization.
2) Or we may give some freedom to the manufacturers of keyboard
   and terminals.

Even though these (00-hexdec to 1f-hexdec and 80-hexdec to 9f-hexdec)
are not legitimately printable while editing a text file, I wish there are
corresponding printable characters such as graphical framing characters
as in IBM PC or a triangle directing left for ^H, not just as the current
'^' which does not distinguish itself from 5e-hexdec.  It will ease
debugging communication problems.

| 00 ^@ nul   80 sml  decreases character size and increases back
  01 ^a soh   81
  02 ^b stx   82 bld  boldifies and unboldifies (toggle)
  03 ^c etx   83
  04 ^d eot   84 dwn  steps down one half line spacing
  05 ^e enq   85
  06 ^f ack   86
  07 ^g bel   87 grp  enters and exits graphics mode
| 08 ^h bs    88 hlp  invokes help universally.
  09 ^i ht    89 itl  italicize and deitalicize from now
  0a ^j nl    8a
  0b ^k vt    8b mlm  mouse left movement    \
  0c ^l np    8c mlb  mouse left button       |
  0d ^m cr    8d mmb  mouse middle button     |
  0e ^n so    8e mdm  mouse downward movement |  Important!
  0f ^o si    8f                              |  no matter what these are
| 10 ^p dle   90 mum  mouse upward movement   |  meta-control keys or
  11 ^q dc1   91 mrm  mouse right movement    |  escape sequences.
  12 ^r dc2   92 mrb  mouse right button     /
  13 ^s dc3   93 scr  sripticizes or unscripticizes (toggle)
  14 ^t dc4   94
  15 ^u nak   95 up   steps up one half line spacing
  16 ^v syn   96 rev  reverses or reverses back characters's black and white
  17 ^w etb   97
| 18 ^x can   98
  19 ^y em    99
  1a ^z sub   9a
  1b ^[ esc   9b atn  escapes during communication calling attention of
                      the local control
  1c ^\ fs    9c
  1d ^] gs    9d
  1e ^^ rs    9e
  1f ^_ us    9f

   Now in the following we have printable  characters except the 'DEL'
key at the end of the lower 7-bit codes.  The alt key may be used to send
the 8-bit code to the host computer
by simulating this key with kermit's 'set key' program such as in
MSFERMIT version 2.30.

   For the 7-bit terminal environment, in which 8-bit signals are not
generated or received by the terminal,
such as VT100, it is desirable for the C-shell or the editor to have a key
which tells the host computer that the next key is one of the upper
8-bit codes (128-255).  This key should not contradict with a control key
of the existing editor programs.   The 'esc' key might be thought the best
choice.  However, most editor programs use this key heavily for some other
purposes.  To avoid conflict, the 'cr (Cntrl-m)' key, which is redundant
both in vi and in gnuemacs (You might have noticed notice that 'C-m' is
changed to 'nl (C-j)' automatically by both editors), may be used.

   This will limit the use of the Meta key in our (or Stallman's) GNU-Emacs.
This actually means no revision in GNU-Emacs.  We just use the ESC key
to invoke the Meta editing keys, although the keyboard has the Meta key.
This is the price we pay
for those Greek characters and the math symbols.  If we use the 'Cntrl-h' for
the real backspace, we have to choose another key for
invoking 'help' in GNU-Emacs.  How about the 'Ext-Cntrl-h' ('88-hexdec')
(or 'C-m C-h' on the 7-bit terminal) as a key for invoking help
in the future version (Ver. 19) of GNU-Emacs.  This is the only change
which is not compatible to the present version (Ver.18).

   I'd like to suggest that the 'Ext-Cntrl-h (88-hexdec)' or 'Cntrl-m Cntrl-
h' on the 7-bit terminal be a new standard key invoking help in e
very software package in the future.  Isn't it a good idea?

| 20 sp    a0 a horizontal bar longer than just '-'.
  21 !     a1 a black square
  22 "     a2 the starting double quotation mark
  23 #     a3 \neq : not-equal sign '/=' in one character site
  24 $     a4 the Pound symbol (U.K. money unit)
  25 %     a5 \div : the division symbol, ':-' in one character site
  26 &     a6 \cap : the common set in set theory, The inverted 'U'.
  27 '     a7 the starting single quatation mark
| 28 (     a8 the top portion of the left parenthesis
  29 )     a9 the top portion of the left parenthesis
  2a *     aa a small circle at the ' level that usually represents degree
  2b +     ab \pm   : '+-' in one character site with + up and - down.
  2c ,     ac the cedilla symbol without c, s, or C.
  2d -     ad \mp   : '-+' in one character site with - up and + down.
  2e .     ae \cdot : a dot at the center
  2f /     af $\dot $ : a dot at the top
| 30 0     b0 the bottom portion of the right parenthesis
  31 1     b1 \propto : the proportionality symbol, 'oc' in one character site
  32 2     b2 \bigcirc : a big circle.
  33 3     b3 \prime \prime \prime : tripple-prime
  34 4     b4 a vertical line with a wart in the middle as in '{'
  35 5     b5 a vertical line with a wart in the middle as in '}'
  36 6     b6 \partial : the mirror image of '6'
  37 7     b7 \cup : the symbol in the set theory, that looks like 'U'
| 38 8     b8 \infty : the infinity symbol, 'oo' in one character site
  39 9     b9 the bottom portion of the left parenthesis
  3a :     ba $\ddot $ : the umlaut, two dots overhead.
  3b ;     bb \prime \prime : the double-prime
  3c <     bc \le    : '_<' in one character site
  3d =     bd \equiv : '=_' in one character site for the defining equality
  3e >     be \ge    : '_>' in one character site
  3f ?     bf \supset : superset symbol
| 40 @     c0 the registered trademark sign, a small capital R in a circle
  41 A     c1 angstrom, a small circle on top of 'A'
  42 B     c2 \rightarrow : an arrow heading east
  43 C     c3 \copyright  : a small capital 'C' in a circle
  44 D     c4 \Delta
  45 E     c5 \in : 'an element of' symbol in set theory
  46 F     c6 \Phi
  47 G     c7 \Gamma
| 48 H     c8 \hbar  : accented italic h for the Planck constant
  49 I     c9 the top portion of the integral symbol
  4a J     ca the bottom portion of the integral symbol
  4b K     cb \simeq :a set symbol (obtained from U by rotating it 90 deg CW)
  4c L     cc \Lambda
  4d M     cd \subset: symbol in the set theory
  4e N     ce \nabla : inverted Greek-capital-Delta
  4f O     cf \Omega
| 50 P     d0 \Pi
  51 Q     d1 \Theta
  52 R     d2 \surd : also makes a \sqrt if combined with underlines (__)
  53 S     d3 \Sigma
  54 T     d4 the trade mark sign, the superscripted 'TM'
  55 U     d5 \Upsilon
  56 V     d6 \leftarrow : an arrow heading west
  57 W     d7 \ddag : the double dagger symbol used for a footnote.
| 58 X     d8 \Xi
  59 Y     d9 \Psi
  5a Z     da \downarrow : an arrow heading south.
  5b [     db \lceil : a vertical line whose top is clamped to the right
  5c \     dc \times : 'x' without serif, math symbol for a multiplication
  5d ]     dd \rceil : a vertical line whose top is clamped to the left
  5e ^     de $\check $ : an accent symbol inverted from '^'
  5f _     df $\overline $ : a long bar on top.
| 60 `     e0 \prime (60-hexdec is a back-prime)
  61 a     e1 \alpha
  62 b     e2 \beta
  63 c     e3 \chi
  64 d     e4 \delta
  65 e     e5 \epsilon
  66 f     e6 \phi
  67 g     e7 \gamma
| 68 h     e8 \eta
  69 i     e9 \iota
  6a j     ea \smallint : the integral symbol, enlongated s
  6b k     eb \kappa
  6c l     ec \lambda
  6d m     ed \mu
  6e n     ee \nu
  6f o     ef \omega
| 70 p     f0 \pi
  71 q     f1 \theta
  72 r     f2 \rho
  73 s     f3 \sigma
  74 t     f4 \tau
  75 u     f5 a wiggle positioned at the underline(_) level.
  76 v     f6 \vec the short arrow symbol that represents a vector
  77 w     f7 $\dagger $ : the dagger symbol used for a Hermitian conjugate
| 78 x     f8 \xi
  79 y     f9 \psi
  7a z     fa \zeta
  7b {     fb \lfloor : a vertical line whose bottom is clamped to the right
  7c |     fc \|      : two vertical lines in one character site
  7d }     fd \rfloor : a vertical line whose bottom is clamped to the left
  7e ~     fe \sim    : a wiggle positioned at the center level
- - - - - - - - - - - - - - - - - - -
  7f del   ff erh  erase the character at the current cursor position
-------------------------------------------------------------

    These all can be reside in the text mode in 8-bit mode so that any text
mode terminal can display them directly on the text mode screen.
The possible benefit of this extension is:

1. If every typesetting program is revised according to the new standard,
   they will become more WYSWYG. It means we do not need to type the '\alpha'
   while typing a TeX file.
2. The wordprocessor and the typesetting programs will be cheaper since they
   do not need to include soft-font files or the hard font ROM.
3. The word processor files can easily be exported and imported from one
   word processor file to another without losing special characters as
   long as they reside in 256 character set.

   In addition to this new extended ASCII, I think that some of the
present ASCII characters should be redesigned from the present
ones as follows:

  " 22    should be designed to look more like the closing double
          quotation mark as in typeset books.
  ' 27    the closing single quotation mark or apostrophe
          same comment as above (" 22-hexdec)
  * 2a    position this a little higher than the present height
          so that it looks like a footnoting symbol, not like a multiplication
          symbol.
  / 2f    stretch this so that two of these can be connected without breaking
          to make a long slanted line.
  \ 5c    the same comment as above
  _ 5f    the same comment as above so that it should be \underbar{ }
  | 7c    make this a single long vertical line rather than the present
          one broken at the middle.

   The current ANSI standard for erasing the previous character is DEL,
not backspace!  Let us encourage everyone to observe this standard.
I know that the troublemaker IBM does not follow this standard.
Let them go their way.  We do not care for IBM.  We are talking about UNIX
and GNU-Emacs and TeX.  Then backspace will do the following job in
GNU-Emacs and vi.

 ^h 08  bs    a backspace key without erasing the previously typed
              character, making an overprinted image when printed. I think this
              special function of this key is actually in the present
              ANSI standard.  You might have noticed that the UNIX 'man'ual
              pages contain '^H' in their text files for underlining.
              It seems now fully supported by most ANSI terminals. (But not on
              IBM's)  Nevertheless, it is not supported by vi or GNU-Emacs.
              Let's encourage Mr.Stallman to support this in his new
              version of GNU-Emacs. It will display every accented
              vowel for foreign alphabets, the
              cent (money unit), some foreign money units, the C-cedilla
              ('Ext-,-backspace-c'), and the null set symbol ('0/' in one
              character site.
              To edit this backspace we need a special character for
              this.  A hollow triangle dirrected to the left is good
              enough.  Also (Emacs maybe not on vi) will have  mode to view
              this while editing.
 ^m 0d  met   In due consideration, the mnemonic should be changed from
              'cr' to 'met'a.


==========================================
    KEYBORAD
-----------------
   This part is not part of my proposal.  I just wish that the new ANSI
ASCII keyboard has the following keys.  One may assign some
function keys for the following purposes.  But it goes
without saying that separate keys at the space bar level are more desirable.

For text/graphics terminals

Italic key : italicizes the normal character. this key should be active
             only on the alpabetic characters, Greek capital characters,
             but not on numeric characters, symbols like '%', '+', '"',etc.
             On a black-and-white text-mode-only terminal which does not have
             ROM to support various fonts (such as VT100),
             it would be desirable if this key reverses white and black
             of those characters between the two italic keys.
             Black becomes white, white becomes black. (Toggle)
Bold key :   boldens or highlights a character. (Toggle)

For graphics terminals

Step-up key : moves the position 1/2-line higher.  and then step down key
             to go back to the original line height.
Step-down key : moves the position 1/2-line lower. and then step-up key
             to go back.
Script key : displays the scripted characters. (Toggle)
Small character key : displays small characters from now and restores the
             size back. (Toggle)

   As to the Keyboard Layout,
We do not need to have the editing keypad on the right.
Why don't we move it to the left leaving more space for the mouse?

=====================================End of draft=======

P.S. At first, I did not intend to do this as a project.  However
it turned out to be a big project.  Now I want to drop
this project and let this free to the public by posting at
the news system here.  I hope everybody to express their
opinion and fruitful discussion here.   And fianlly I hope to see ANSI
or POSIX committee act.

Please start this project and act, ANSI.

Volume-Number: Volume 13, Number 39

From jsq  Sat Apr  2 20:03:01 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09808; Sat, 2 Apr 88 20:03:01 EST
From: Ralph Hyre <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Machine Readable ANSI C Std?
Summary: license it?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ralph Hyre)
Organization: Carnegie-Mellon University, CS/RI
Date: 1 Apr 88 20:46:05 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Ralph Hyre)

In article <[e-mail]>:
>From: [e-mail]
>
>    Is there a machine readable copy of the ANSI C standard available?
>Alas, no.  ANSI makes its money from publishing standards.  If there was
>a machine readable copy of the standard around for anonymous ftp, then many
>people would get a hold of it that way, rather than buy it from ANSI.
....
>My own personal opinion is that standards ought to be developed by some
>sort of subsidized, not-for-profit organization, and be available at media
>cost.  (For all I know ANSI may BE "not-for-profit".  That still doesn't
>mean they'll give away the standards they create.)

Licensing the standards documents would be another alternative, then you'd
have competition among the various licensees for price and the kinds of
distributions available.  Another alternative would be charging members for
ANSI membership, but this might discourage smaller companies from joining,
(or encourage large companies to stack the deck) and politicize the process
even more.

There's no reason that USENIX or some similar group couldn't come up with a
Unix standard, but that would violate the spirit of what ANSI is trying to do.

[ I'm pretty sure the USENIX board of directors wouldn't be interested.
Doubtless everyone is aware that IEEE 1003 began as the /usr/group Standards
Committee, and that /usr/group currently sponsors the /usr/group Technical
Committee, which investigates areas that 1003 hasn't reached yet.  -mod ]

--
                    - Ralph W. Hyre, Jr.

Internet: [e-mail]    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

Volume-Number: Volume 13, Number 40

From uucp  Tue Apr  5 02:14:26 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA29565; Tue, 5 Apr 88 02:14:26 EDT
From: Jim Barton <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX standard
Summary: Oh no, back again ...
Keywords: UNIX SPARC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim Barton)
Organization: Silicon Graphics Inc, Mountain View, CA
Date: 29 Mar 88 17:23:10 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Jim Barton)

Having been justifiably chastised by the moderator, I'll keep my personal
opinions to myself, and stick with the issue at hand, which is "standard"
UNIX.

In article <[e-mail]>:
> From: uunet!wlbr.eaton.com!etn-rad!jru (John Unekis)
   ...
>
>   ........ My question was actually more concerned with the future of UNIX
>   as an open standard. Obviously keeping UNIX open is a double edged sword
>   for AT&T, they gain great credit as the source of the most widely accepted
>   non-hardware dependent OS, but does it really benefit the sales of their
>   machines? If AT&T were ever to pick a hardware standard as the basis for
>   a product dependent UNIX, the SPARC would be an excellent choice. The
>   real question, I suppose, is can an open standard like UNIX really survive
>   in today's feircely competitive marketplace?
>

AT&T has some real problems in attempting to manage UNIX, and looks to Sun
to solve some of them.  There are several points to consider about the
current mess:

1) AT&T >owns< UNIX, and don't you forget it.  Sun doesn't own it, Berkeley
   doesn't, and CMU doesn't.  They feel very strongly about it.

2) Cassoni (President of AT&T Data Systems) believes that a hardware
   platform is necessary to the success of UNIX, similarly to the
   IBM PC.  I obviously don't.  The PC is basically hardware, and thus
   a different beast than UNIX.  By making UNIX hardware specific, you
   destroy it.

3) AT&T licenses UNIX to a large number of people in various ways.  Were
   they to take action that would seriously harm a large number of licensees
   (especially the big ones) they would be facing an anti-trust suit so
   fast your head would spin.

4) AT&T and Sun are attempting to define a new standard by a simple existence
   proof, the infamous "open" standard.  This group has carried much
   discussion about P1003 and other efforts; those are a "standard".  AT&T
   and Sun wish to define a standard suitable for their own uses without
   going through the hassle of getting everybody to agree - thus bypassing
   most of the technical community.  Thus, they want an IBM style "standard".
   This is the current, openly announced, plan for V.4.

5) The "open" standard and promises to licensees are efforts by AT&T to
   pacify competitors.  It is clearly to AT&T's advantage to have a "standard"
   which looks open on the surface (i.e., everybody >could< duplicate it
   without AT&T source code), but is really as closed as possible (you
   really have to buy AT&T source and hardware to realize it).  This is
   true today.  Consider RFS, which is in SVID Issue 3, but is un-implementable
   from the SVID as specified.  Somehow, though, this is a "standard".

6) You've obviously been hiding under a rock for the past six months.  A
   large number of UNIX licensees have complained directly to AT&T about
   the AT&T/Sun deal and the pronouncements by Sun salespeople.  AT&T
   has come out with many assurances that they will take care of
   everybody.  Rumoured deals are in the making to work on competing
   versions of UNIX (though obviously >not< with that name).

I'd like to make one last point.  A "competing" standard arose with Berkeley
UNIX because of the legally restricted support that AT&T had to give
originally and because of the anti-UCB sentiment back in New Jersey.  By
attempting to force one standard without the technical and business input
of the UNIX licensees, AT&T engenders an environment where another
competing standard can rise and flourish.  After all, V.4 will have
Sun's favorite enhancements, but it won't have mine, or yours, and it may
break what I do have.

The heavy-handedness of the AT&T/Sun actions may do more to trash any
emerging UNIX standard than to promote it.

-- Jim Barton
Silicon Graphics Computing Systems    "UNIX: Live Free Or Die!"
[e-mail], sgi![e-mail], ...{decwrl,sun}!sgi!jmb
--

Volume-Number: Volume 13, Number 39

From uucp  Tue Apr  5 02:19:49 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA29761; Tue, 5 Apr 88 02:19:49 EDT
From: Kent Paul Dolan <[e-mail]>
Newsgroups: comp.std.unix
Subject: SPARC name conflict noted
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Kent Paul Dolan <[e-mail]>
Date: 29 Mar 88 16:23:07 GMT
Apparently-To: std-unix-archive
Status: O

From: Kent Paul Dolan <[e-mail]>

John,

Comment only: "SPARC" is a _horrible_ choice of names for a product
connected with an ANSI (UNIX) standard, since the acronym is already
used _within_ ANSI for its Standards Planning And Review Committee.

I was on my third AT&T/Sun/SPARC posting reading before I realized
that this committee was _not_ the subject matter!  (I was once a
member of ANSI/X3H3; thence the strong association.)

This name conflict can do nothing but lead to endless confusion within
standards efforts involving this product, and so I recommend that
"SPARC" should be quickly replaced with a less overloaded name by
AT&T/Sun.

Kent, the man from xanth.

(Usual "every proper name used herein (but mine) is probably a
trademark of somebody" disclaimer.)

Volume-Number: Volume 13, Number 40

From uucp  Tue Apr  5 02:55:54 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA00634; Tue, 5 Apr 88 02:55:54 EDT
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: ANSI membership fees.  (was: Machine Readable ANSI C Std?)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Apr 88 14:55:50 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail]
Cc: [e-mail] (Ralph Hyre)

    Another alternative
    would be charging members for ANSI membership, but this might
    discourage smaller companies from joining, (or encourage large
    companies to stack the deck) and politicize the process even more.

If by "members" you mean members of ANSI committees, then we are
charged!  Each member of X3J11 pays an annual fee (I think it went up
to $200.00 this year) to CBEMA, the Computer and Business Equipment
Manufacturer's Association, for membership on X3J11.  This fee pays for
the overhead of creating the standard.  ANSI gets its money from
selling the completed standard.  This fee is a bigger burden on small
companies (or individuals; I payed my own way for the first 2 years I
was on X3J11) than it is on large.  However, the fee is really nothing
compared to the travel costs and lost time.  I did a very rough
calculation once of the cost of producing the C standard.  I think
$10,000,000 is in the right ballpark.  Don't get the idea, however,
that committee membership is really cheap for the the large companies. In
general, the large companies sponsor meetings, a non-trival expense, and
do our mailings, which are a great expense in time and money.  Creating
a standard such as X3.159 is very expensive!

Under the current rules, large companies can't stack the deck, since any
given entity (company, government agency, individual) can have only
one representative and one alternate on any ANSI committee.

Volume-Number: Volume 13, Number 40

From uucp  Tue Apr  5 03:28:35 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA05757; Tue, 5 Apr 88 03:28:35 EDT
From: Dave Sill <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Dave Sill <[e-mail]>
Date: 4 Apr 88 20:21:29 GMT
Apparently-To: std-unix-archive
Status: O

From: Dave Sill <[e-mail]>

In article <[e-mail]> Ghie-Hugh Song <[e-mail]> writes:
>Have you ever dreamed that TeX were more WYSWYG or that you could type
>Greek characters in the text mode directly?  If we had an extended
>256 8-bit ASCII character set such as IBM PC's. (See Appendix of
>PC DOS Manual), things would be much easier.
>
> [Proposed 8-bit ASCII deleted.]

There was a time when I would have supported such a proposal.  I'd
particularly like to have such extended characters for use in
programming languages (a left-arrow character for assignment, for
example) and in shells (to take the place of metacharacters such as:
<>*&| et cetera that also have normal meanings as punctuation.)

However, I can't see that any fixed 8-bit or 9-bit or even 16-bit code
will be able to meet future requirements.  It would only be a matter
of time before people started to complain about characters not in the
standard set.

I think a more powerful and flexible system based on the current 7-bit
ASCII would be better.  Bill Joy, in the April issue of Unix Review,
says PostScript is the new ASCII.  I'm inclined to agree that
a PostScript like language would fill the bill better over the long
run (next 10-20 years) than a fixed code.  This would also allow the
internationalization effort to be integrated nicely.  Do any
PostScript/TeX/Metafont weenies care to argue the merits of their
favorite system?

Input and output devices capable of handling such extended character
sets are another problem.  I don't think ctrl/meta/alt/cokebottle keys
on qwerty keyboards are the best way to go, but neither are keyboards
with hundreds of keys.  It would probably be better to have smart
keyboards and drivers that would recognize escape sequences and
replace them with associated extended characters.

Output devices, in general, are more capable.  Except for daisy-wheel
printers and dumb terminals, most have graphics capabilities that
could be put to use.  For the ever-important backward compatibility,
though, some scheme would have to be devised.  Perhaps a pseudo-
PostScript for ASCII-only devices could be devised that would display
everything in one font and get the spacing as close as possible to
what was intended.

Oh well, I'm rambling...

=========
The opinions expressed above are mine.

"I no longer think of something as a computer unless
 it's connected to a network."
                    -- Peter Weinberger


Volume-Number: Volume 13, Number 41

From uucp  Tue Apr  5 03:29:49 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA05837; Tue, 5 Apr 88 03:29:49 EDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 4 Apr 88 21:11:13 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Guy Harris)

>    I understand that the standardization of 8-bit extended ASCII
> is too late.

You're probably right.  There is already a family of ISO extended character
sets, the ISO 8859 family, that are extensions of ASCII and are being adopted
by many UNIX systems.  The ISO 8859/1 character set, also known as "ISO Latin
Alphabet #1", has been adopted or will be adopted by a number of vendors for
Western European use; AT&T has adopted t, Sun plans to do so, I believe Apollo
has done so, DEC's international character set is similar to it and they may
have adopted it, and I think X/Open has already specified it.

Volume-Number: Volume 13, Number 42

From uucp  Tue Apr  5 03:30:42 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA05880; Tue, 5 Apr 88 03:30:42 EDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX standard
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 4 Apr 88 21:27:33 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Guy Harris)

   We recently had some SUN reps come to give a presentation about SPARC.
   They were strongly suggesting that due to their relationship with AT&T
   (that is AT&T will soon sell SPARC) it will soon be the case that if you
   are not a SPARC machine you will not *really* be UNIX compatible.

If they were truly suggesting this, it merely indicates that Sun (not all caps,
PLEASE! - it's not an acronym for Stanford University Network when used to
refer to Sun Microsystems, Inc.)  salespeople are as 1) uninformed about
reality and/or 2) over-eager to sell their product as any other vendor's
salespeople.  If you are not a SPARC machine, you will be 100% UNIX-compatible
as long as you pass whatever validation suites the person asking you "are you
UNIX-compatible" wants to use, such as the SVVS.  The SVVS won't test whether a
machine is a SPARC or not.

There may be tests to see whether a SPARC-based machine conforms to the SPARC
Applications Binary Interface, but if there is there'll probably be similar
test for the 80386-and-up ABI, and the 68020-and-up ABI, and....

   They were talking about a coming binary standard, so that you could buy a
   program written for UNIX and know that it would run on your UNIX machine
   the same way you know that PC software will always run on your Intel/PC.
   This binary standard would assumably be based on the SPARC instruction
   set.

There are several binary standards arriving on the market.  For each one of
them, you could buy a program written for UNIX *and* compiled for the
architecture in question and know that it will run on UNIX machines using that
architecture.  There are, for example, standards coming out for the
80386-and-up family and for the 68020-and-up family.  There will be one for
SPARC.  There may well be others coming out for various non-"in-house-only"
chips (MIPS, Motorola 88000, etc.).

   Is this stuff true or is it just marketing hype? Is UNIX really going to
   become hardware dependent? What about all of us out here with our 680x0
   or 80x86 or VAXen or whatever? Are we going to be second-class UNIX users,
   unable to run the bulk of UNIX software? Can anybody out there clarify
   this?

They won't be able to run SPARC binaries, but SPARC-based machines won't be
able to run 68K binaries, either (unless somebody does emulation product - no
comment on whether such a thing exists, or is planned, or...).

It may be that some chips will end up having more UNIX software built for them
than others, and that the others will end up being "second-class UNIX users",
unable to run a lot of UNIX software.  Such are the vagaries of the
marketplace; there's no guarantee that SPARC will end up in one or the other of
those sets.  Obviously, we'd like it to end up in the former set, just as
Motorola would like the 68020-and-up and 88K to end up there, and Intel would
like the 80386-and-up to end up there, and MIPS would like the MIPS chips to
end up there, and....

Volume-Number: Volume 13, Number 43

From uucp  Wed Apr  6 13:36:00 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA08155; Wed, 6 Apr 88 13:36:00 EDT
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!harvard.harvard.edu!haddock!karl (Karl Heuer)
Organization: Interactive Systems, Boston
Date: 5 Apr 88 15:47:27 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!harvard.harvard.edu!haddock!karl (Karl Heuer)

In article <[e-mail]> [e-mail] (Ghie-Hugh Song ) writes:
>Have you ever dreamed that TeX were more WYSWYG or that you could type
>Greek characters in the text mode directly?  If we had an extended
>256 8-bit ASCII character set such as IBM PC's. (See Appendix of
>PC DOS Manual), things would be much easier.

Well, actually I've wished for a *lot* of non-ASCII characters at various
times.  More than you can fit in the 128 available slots.  But most of them
are so seldom used that I don't mind that they don't have reserved 8-bit
values.

>For the 7-bit terminal environment, in which 8-bit signals are not generated
>or received by the terminal, such as VT100, it is desirable for the C-shell
>or the editor to have a key which tells the host computer that the next key
>is one of the upper 8-bit codes (128-255).  This key should not contradict
>with a control key of the existing editor programs.

There is no such key.  (Yes, Emacs *does* distinguish between C-m and C-j.
Besides, on most keyboards the big key labeled RETURN or ENTER generates C-m,
so if you preempt that for a pseudo-meta, you'd have to use an explicit C-j
(awkward to type) to get a newline.)  Not that it matters -- such editors
normally run in raw mode anyway, so they'd be bypassing the new feature.

>In addition to this new extended ASCII, I think that some of the present
>ASCII characters should be redesigned from the present ones as follows:
>[suggests, among other changes, that /\_| should be stretched to fit the
>character cell]

If you want line-drawing characters, add a line-drawing font.  Don't try to
make the ASCII set do double duty.

>... You might have noticed that the UNIX 'man'ual pages contain '^H' in their
>text files for underlining.  It seems now fully supported by most ANSI
>terminals.

Oh?  Underlining with backspace is not unheard of, but I think the escape
sequence \e[4m is more common, especially among "ANSI terminals".  Perhaps
you're confused by software that does this conversion for you (e.g. "more")?
And certainly very few terminals (hardcopy excepted) will display general
overstrikes like a cent sign.

Volume-Number: Volume 13, Number 41

From uucp  Thu Apr  7 21:29:39 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA10260; Thu, 7 Apr 88 21:29:39 EDT
From: (rja <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (rja)
Organization: GE-Fanuc North America
Date: 7 Apr 88 13:01:40 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (rja)

  I'd thought someone else would have pointed this out, but nothing has
shown up at edison to correct the misconception.  THERE IS AN 8-bit
STANDARD, ISO 8859/1.  It also has other variants (8859/2, etc.) which
support other languages.  The 8859/1 version supports nearly ALL languages
in use in Western Europe.  It is a proper superset of ASCII.

[ Actually, Guy Harris already pointed this out.  But your following
observation is quite useful.  -mod ]

For more details, please tune into the ongoing discussions in
comp.std.internat, where several people have voiced concerns over
languages NOT supported.  Nevertheless, since it is being adopted as an
X/OPEN standard and big companies like AT&T are adopting it, expect it
to take hold.

Volume-Number: Volume 13, Number 47

From uucp  Thu Apr  7 22:31:59 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA15921; Thu, 7 Apr 88 22:31:59 EDT
From: Mike Threepoint <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mike Threepoint)
Organization: The Society for Creative Euthanasia
Date: 7 Apr 88 11:12:59 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Mike Threepoint)

Bo Thide (irf@kuling) recently described it [ISO 8859/1 -mod] as 191
characters cleverly designed with capitals coded as shifted miniscules,
including eth (which I'm not sure what it is), thorn, and sharp S.

To possibly add to the list, this sounds like the character set
Microsoft Windows uses and terms (by no standard I know of) "ANSI".
It has the vowels in acute, grave, circumflex, tilde, and umlaut.
The high bit characters also include cent, pound, yen, and universal
currency symbols, circle-R trademark and circle-C copyright symbols,
inverted ? and !, section and paragraph symbols, << guillemets >>,
several accents, 1/4, 1/2, and 3/4 characters, and superscripted 1, 2,
and 3.  The last sound like a bad idea to me, so I actually hope this
is something they threw together themselves.

Sound like ISO 8859?  If not, I would be quite interested to know just
what it is.  How much do I send to where (if you can't just mail me a
copy)?

What I would also like to see is the ASCII 0..1F (31 dec.) graphic
representations on new machines conform to the ANSI standard.  They
might look impractical, but after setting up a font using them on my
micro, it's amazing how much sense they make to me.

--
"Science does not remove the terror of the gods."  | Mike Threepoint
            -- J.R. "Bob" Dobbs       | [e-mail]
"One man's theology is another man's belly laugh." | FidoNet 1:107/513
            -- Lazarus Long           | AT&T [phone]

Volume-Number: Volume 13, Number 48

From uucp  Fri Apr  8 13:29:00 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09236; Fri, 8 Apr 88 13:29:00 EDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 8 Apr 88 05:38:39 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (Guy Harris)

> To possibly add to the list, this sounds like the character set
> Microsoft Windows uses and terms (by no standard I know of) "ANSI".
> It has the vowels in acute, grave, circumflex, tilde, and umlaut.
> The high bit characters also include cent, pound, yen, and universal
> currency symbols, circle-R trademark and circle-C copyright symbols,
> inverted ? and !, section and paragraph symbols, << guillemets >>,
> several accents, 1/4, 1/2, and 3/4 characters, and superscripted 1, 2,
> and 3.  The last sound like a bad idea to me, so I actually hope this
> is something they threw together themselves.

> Sound like ISO 8859?

Yes.  The superscripted letters *do* come from ISO 8859 (see below).

> What I would also like to see is the ASCII 0..1F (31 dec.) graphic
> representations on new machines conform to the ANSI standard.  They
> might look impractical, but after setting up a font using them on my
> micro, it's amazing how much sense they make to me.

What "graphic representations" are you referring to?  The only ANSI standard I
know of for characters in the range 0x00 to 0x1f is ASCII, which says they're
*control* characters, not *printable* characters.

For your collective amusement, here is a chart of ISO 8859/1 or "ISO Latin
Alphabet #1".  This was derived by some quick hacking on the X11 include file
"keysymdef.h" - yes, X11 uses the ISO character sets as well.

non-breaking space        0xa0
inverted exclamation point    0xa1
cent sign            0xa2
pounds sterling            0xa3
"currency symbol"        0xa4
yen                0xa5
broken bar            0xa6
section mark            0xa7
diaeresis            0xa8
copyright            0xa9
feminine ordinal        0xaa
        (this is a subscripted lower-case "a", underlined)
left guillemot            0xab
        (French left quote, looks like small "<<")
not sign            0xac
hyphen                0xad
registered trademark        0xae
macron                0xaf
        (an elevated small horizontal bar)
degree symbol            0xb0
plus/minus            0xb1
superscript 2            0xb2
superscript 3            0xb3
acute accent            0xb4
mu                0xb5
paragraph symbol        0xb6
small centered dot        0xb7
cedilla                0xb8
superscript 1            0xb9
masculine ordinal        0xba
        (this is a subscripted lower-case "o", underlined)
right guillemot            0xbb
        (French right quote, looks like small ">>")
1/4                0xbc
1/2                0xbd
3/4                0xbe
inverted question mark        0xbf
A with grave accent        0xc0
A with acute accent        0xc1
A with circumflex accent    0xc2
A with tilde            0xc3
A with diaeresis        0xc4
A with ring            0xc5
        (as in "Angstrom")
AE dipthong            0xc6
C with cedilla            0xc7
E with grave accent        0xc8
E with acute accent        0xc9
E with circumflex accent    0xca
E with diaeresis        0xcb
I with grave accent        0xcc
I with acute accent        0xcd
I with circumflex accent    0xce
I with diaeresis        0xcf
upper-case eth            0xd0
        (eth is an Icelandic letter)
N with tilde            0xd1
O with grave accent        0xd2
O with acute accent        0xd3
O with circumflex accent    0xd4
O with tilde            0xd5
O with diaeresis        0xd6
multiply sign            0xd7
O with slash            0xd8
U with grave accent        0xd9
U with acute accent        0xda
U with circumflex accent    0xdb
U with diaeresis        0xdc
Y with acute accent        0xdd
upper-case thorn        0xde
        (thorn is an Icelandic letter)
German double-s            0xdf
a with grave accent        0xe0
a with acute accent        0xe1
a with circumflex accent    0xe2
a with tilde            0xe3
a with diaeresis        0xe4
a with ring            0xe5
        (lower-case "A with ring")
ae dipthong            0xe6
c with cedilla            0xe7
e with grave accent        0xe8
e with acute accent        0xe9
e with circumflex accent    0xea
e with diaeresis        0xeb
i with grave accent        0xec
i with acute accent        0xed
i with circumflex accent    0xee
i with diaeresis        0xef
lower-case eth            0xf0
n with tilde            0xf1
o with grave accent        0xf2
o with acute accent        0xf3
o with circumflex accent    0xf4
o with tilde            0xf5
o with diaeresis        0xf6
division sign            0xf7
o with slash            0xf8
u with grave accent        0xf9
u with acute accent        0xfa
u with circumflex accent    0xfb
u with diaeresis        0xfc
y with acute accent        0xfd
lower-case thorn        0xfe
y with diaeresis        0xff

Volume-Number: Volume 13, Number 49

From uucp  Sat Apr  9 19:58:06 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA04772; Sat, 9 Apr 88 19:58:06 EDT
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Summary: ISO 6937
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!rutgers.edu!mtune!homxb!hrs (H.SILBIGER)
Organization: AT&T Bell Laboratories, Holmdel
Date: 9 Apr 88 13:57:53 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!rutgers.edu!mtune!homxb!hrs (H.SILBIGER)

In article <[e-mail]>, [e-mail] (Guy Harris) writes:
> From: [e-mail] (Guy Harris)
>
> > currency symbols, circle-R trademark and circle-C copyright symbols,
> > inverted ? and !, section and paragraph symbols, << guillemets >>,
> > and 3.  The last sound like a bad idea to me, so I actually hope this
> > Sound like ISO 8859?
>
> Yes.  The superscripted letters *do* come from ISO 8859 (see below).
>
>
There is another ISO standard that handles all latin alphabets, known as
ISO6937.  There is a CCITT equivalent.

This character set is characteristically used in text communication
applications, such as document architecture, teletex, message handling, etc.

ISO 8859 is used mainly in the computer processing environment.

[ Because ISO 6937 buys extreme flexibility by composing characters as
two-byte combinations of basic character and accent, while ISO 8859
encodes every character as one byte.  I saw this on comp.std.internat,
which I recommend everybody interested in this discussion should read.  -mod ]

Herman Silbiger batavier![e-mail]

Volume-Number: Volume 13, Number 50

From uucp  Thu Apr 14 05:18:56 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA24658; Thu, 14 Apr 88 05:18:56 EDT
From: Peter da Silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: sugar!peter (Peter da Silva)
Organization: Sugar Land UNIX - Houston, TX
Date: 14 Apr 88 00:54:17 GMT
Apparently-To: std-unix-archive
Status: O

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

>  From: [e-mail] (Guy Harris)
> The ISO 8859/1 character set, also known as "ISO Latin
> Alphabet #1", has been adopted or will be adopted by a number of vendors for
> Western European use; AT&T ... Sun ... Apollo ... DEC ...

Add the Commodore Amiga and (I think) the Atari ST to the list...
--
-- Peter da Silva      `-_-'      ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These aren't mere opinions, these are *values*.


Volume-Number: Volume 13, Number 51

From uucp  Fri Apr 15 13:46:37 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA08154; Fri, 15 Apr 88 13:46:37 EDT
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: 8-Bit ASCII Standard on UNIX-POSIX
Summary: ANSI X3.32 "Graphic Representation of the Control Characters of ASCII"
Keywords: Yale, Master...
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!topaz.rutgers.edu!linhart (Mike Threepoint)
Organization: The Society for Creative Euthanasia
Date: 15 Apr 88 01:40:47 GMT
Apparently-To: std-unix-archive
Status: O

From: uunet!topaz.rutgers.edu!linhart (Mike Threepoint)

u <- [e-mail] (Guy Harris)

When we last left our conversation:
[description of MS Windows "ANSI" character set]
me> Sound like ISO 8859?

u> Yes.  The superscripted letters *do* come from ISO 8859 (see below).

Thanks to your table, I can confirm that they match.  Multiply and
divide symbols are missing, replaced by the ubiquitous empty box, but
now my EGA font is complete (for my IBM compatible, made with CHET, I
could post it to binaries if anyone really wanted it).

me> What I would also like to see is the ASCII 0..1F (31 dec.) graphic
me> representations on new machines conform to the ANSI standard.  They
me> might look impractical, but after setting up a font using them on my
me> micro, it's amazing how much sense they make to me.

u> What "graphic representations" are you referring to?  The only ANSI standard
u> I know of for characters in the range 0x00 to 0x1f is ASCII, which says
u> they're *control* characters, not *printable* characters.

The rather obscure ANSI X3.32-1973 "Graphic Representation of the
Control Characters of ASCII" defines them for use when the
name-in-tiny-letters isn't used.  I found it in Joe Cambell's "C
Programmers Guide to Serial Communications" (Howard W. Sams & Co.)
[wish I had a copy of my own, had to reborrow it to get the ID] which
contains an ASCII chart poster with those symbols on it.

It goes something like this:  (they're in that aforementioned font, too)

^@    NUL    a hollow square, like the one used in Mac character sets for
        undefined characters
^A    SOH    the left column and top row of the cell set, like an
        inverted L
^B    STX    the bottom row and center column set, like a
        perpendicular symbol
^C    ETX    the right column and bottom row set, like a reversed L
^D    EOT    a single zig-zag, like a lightning bolt
^E    ENQ    a square with an X in it
^F    ACK    a check mark (tick mark to you Europeans)
^G    BEL    a hemisphere with two L shaped feet, I want to say
        "doodlebug", but it's probably more like an
        electronic component
^H    BS    an up arrow bent over leftwards into a U-shaped hook
        at the top
^I    HT    a right arrow with the barbs extended to the length of
        the shaft, more like a dart
^J    LF    three parallel horizontal lines
^K    VT    a downward pointing dart [Campbell says that instead
        of overloading LF with NewLine worsening the present
        incompatibilites, ANSI should have redefined this
        almost totally unused character]
^L    FF    a down dart with a second arrowhead midway down its
        shaft
^M    CR    a left dart
^N    SO    a circle with an X in it
^O    SI    a circle with a dot in the center
^P    DLE    a square with a horizontal line through the middle
^Q    DC1    a circle with the top right quarter sectioned off,
        that is, lines from the center to the top and right
^R    DC2    same, but lower right quarter
^S    DC3    same, but lower left quarter
^T    DC4    same, but top left quarter
^U    NAK    a check (tick) mark with a horizontal line thru the
        center
^V    SYN    a rectangle with the bottom cut in half and turned
        outward, like a bottomless rectangle with feet
^W    ETB    the right column and center row set, a T on its side
^X    CAN    a down pointing hollow triangle on an up pointing one,
        like an hourglass
^Y    EM    a vertical line with a fat dot in the middle
^Z    SUB    a backwards ?
^[    ESC    a circle with a line through the center
^\    FS    a square box with the top left quarter sectioned off
^]    GS    same, but bottom left
^^    RS    same, but bottom right
^_    US    same, but top right

u> For your collective amusement, here is a chart of ISO 8859/1 or "ISO Latin
u> Alphabet #1".  This was derived by some quick hacking on the X11 include
u> file "keysymdef.h" - yes, X11 uses the ISO character sets as well.
[table deleted]

Thanx, I appreciate it.  I'm still interested in 8859-3 (which I read
supports Esperanto), if it's not too much trouble could you tell me
a) what _its_ layout is, or b) how much to send to where?
--
"...billions and billions..."            | Mike Threepoint (D-ro 3)
            -- not Carl Sagan    | [e-mail]
"...hundreds if not thousands..."        | FidoNet 1:107/513
            -- Pnews        | AT&T [phone]

Volume-Number: Volume 13, Number 52

From uucp  Fri Apr 15 13:52:32 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA08357; Fri, 15 Apr 88 13:52:32 EDT
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: AT&T "open look" "standard"
Summary: Bonus extra info...
Message-Id: <[e-mail]>
Reply-To: Rich Salz <uunet!BBN.COM!rsalz>
Organization: BBN Laboratories, Cambridge MA
Date: 14 Apr 88 16:47:14 GMT
Apparently-To: std-unix-archive
Status: O

From: Rich Salz <uunet!BBN.COM!rsalz>

This appeared in comp.windows.news, but might be worthwhile posting here...

I deleted a second press release about AT&T training conferences,
but the following paragraph is very intersting:
    Further, the conference will cover UNIX System V Release 4.0's
    key capabilities in the areas of networked computing and user
    interfaces.  For example, in the networking area, UNIX System V
    Release 4.0 brings together AT&T's  Remote  File  Sharing and
    Sun's Network File System (NFS), Remote Procedure Call (RPC) and
    External Data Representation (XDR).  In the area of user
    interfaces, Release 4.0 adds graphics and windowing capabilities
    to UNIX System V's set of character oriented capabilities.  The
    OPEN LOOK interface will provide a common look and feel across
    the UNIX  system in  either a  standalone or networked
    environment using either X Windows or X11/NeWS.
Yup, V.4 will support NFS and X ...

[ I've mulled over the propriety of posting a company press release
for a bit.  It seems appropriate this time because no one from AT&T
has contributed to the previous discussion, and this press release
at least give some idea of what AT&T is trying to do.  -mod ]

From: [e-mail] (Joel McClung - Federal TS Mgr Washington DC)
Newsgroups: comp.windows.news
Subject: Press Release-AT&T Look & Feel
Date: 12 Apr 88 00:04:17 GMT


          AT&T ANNOUNCES OPEN LOOK GRAPHICAL USER INTERFACE
                  FOR RELEASE MONDAY, APRIL 11, 1988

New York -- AT&T today announced an advance that will make it
easier for many customers to use computers based on the
company's UNIX(R) operating system.

Called the OPEN LOOK(TM) user interface, it employs common-sense
graphic symbols instead of written commands to help users work
more efficiently with their UNIX System V-based computers.

"OPEN LOOK will change the way the industry thinks of the UNIX
system," said Vittorio Cassoni, president of AT&T's Data Systems
Group.  "This interface brings the benefits of the UNIX system
to a whole new group of users who otherwise might never have
taken advantage of the power of a UNIX system-based computer."

The OPEN LOOK technology was designed for AT&T by Sun
Microsystems Inc. of Mountain View, California.  Sun's design is
based on original work, contributions from AT&T, and on
technology licensed from Xerox Corporation, which originated
many of the concepts present in today's computer interfaces.

The OPEN LOOK interface's graphic symbols include push pins to
"pin" important menus to the screen for further reference and an
elevator to move up or down in the text.  To print or store
files, users move a hand-held mouse to push labeled buttons
designed to look like those on a household appliance.

"As the name implies," said Cassoni, "the OPEN LOOK user
interface supports AT&T's commitment to open systems and the
need for a standard user interface."

This interface represents the next critical step in truly
expanding the UNIX system marketplace," said Scott McNealy,
president of Sun Microsystems.  "Applications developed with the
OPEN LOOK interface can vie for a larger market because the
interface is standard."

The interface has already generated endorsements from key
computer system suppliers, PC and workstation software suppliers
and systems suppliers.

"We believe this is what the industry has been waiting for,"
said Cassoni, adding that endorsements by key MS-DOS application
vendors represent a watershed in the evolution of the UNIX
system.

"Lotus' goal is to provide its customers with common
applications such as 1-2-3 across standard platforms," said Jim
P. Manzi, president and CEO of Lotus Development Corporation.
"Until recently, the variants of the UNIX system were a barrier
to that goal.  The OPEN LOOK interface exemplifies a movement
toward a more standardized UNIX environment.  This movement has
encouraged vendors like Lotus to develop UNIX system versions of
proven applications such as 1-2-3."

"We consider the UNIX system environment a strategic development
platform today and in the future," said Edward M. Esber, Jr.,
chairman and CEO of Ashton-Tate Corporation.  "The OPEN LOOK
user interface will play an important role in helping us to
provide our customers with powerful, yet easy-to-use UNIX system
applications."

Wayland R. Hicks, president of Xerox Corporation's Business
Products and Systems Group said, "Xerox is endorsing the OPEN
LOOK interface as a future building block for Xerox  document
processing products and systems."

UNIX System V is the fastest-growing operating system, according
to industry  sources,  with worldwide shipments of UNIX
system-based computers expected to grow at an annual rate of 30
percent over the next three  years.  AT&T said the OPEN LOOK
user interface should make the UNIX system even more popular by
making it easier to use.

The interface offers benefits for users and application
programmers alike.

In addition to being easy for them to learn, the OPEN LOOK
interface will make users more productive because it allows them
to create multiple "windows" on their computer screens, each of
which can perform a different task simultaneously.

Programmers will find that the various Application Programmer
Interface (API) Toolkits AT&T plans  to release will give them a
set of tools -- or pre-programmed components -- to make it more
efficient to write new applications by reducing the amount of
code that needs to be written per function.

In addition, because the OPEN LOOK user interface is the
standard interface for UNIX system-based computers, programmers
don't have to be retrained to write software for different
machines -- thus, increasing their productivity.

AT&T will circulate OPEN LOOK specifications for comment this
summer and will make them available in the third quarter of this
year.  These will include a specification of the common style
for  applications -- the Applications Style Guide -- as well as
descriptions of the programming interface for OPEN LOOK under
two toolkits, both of which AT&T will support via a single
graphics system platform.  They are the XT toolkit based on the
X Windows and the NDE toolkit based on NeWS.

The first availability of OPEN LOOK features in an AT&T product
will be this summer in a window manager for the 6386
workstation, followed by an XT toolkit in the fourth quarter
1988 and an NDE toolkit in the first quarter 1989.

In keeping with its commitment to support standards, AT&T said
that as they  become  accepted, the company would support APIs
for emerging standard interfaces.  AT&T also will license source
code for the various toolkits supporting the OPEN LOOK user
interface.

The OPEN LOOK user interface toolkits are scheduled to be available in
source form in early 1989.

The OPEN LOOK user interface is designed to be useful into the
1990's.  For instance, unlike some graphical interfaces, the
OPEN LOOK interface is designed for a wide range of applications
from simple document processing  to  much  more  sophisticated
computer-added  engineering (CAE).  In addition, the graphics
perform well whether they appear on a PC or a high resolution
engineering workstation.  Also, the interface will support a
variety of terminals accessing different  applications.

AT&T today also announced it will co-sponsor with Sun
Microsystems a series of eight, three-day conferences around the
world beginning in September to give independent software
vendors, value-aided resellers and large corporate users a
preview of the key technical features of UNIX System V Release
4.0, including the newly announced OPEN LOOK interface.

"Today's announcement, "Cassoni concluded, "further delivers on our
promise to provide our customers with the world's premiere computer
operating system."

                                 ###

OPEN LOOK is a trademark of AT&T.  UNIX is a registered  trademark  of
AT&T.
--
Please send comp.sources.unix-related mail to [e-mail].

Volume-Number: Volume 13, Number 53

From uucp  Fri Apr 15 14:26:37 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09275; Fri, 15 Apr 88 14:26:37 EDT
From: David Brooks <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8-bit discussion in std-unix
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (David Brooks)
Date: 13 Apr 88 16:22:44 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (David Brooks)

(this may be a duplicate.  I don't trust our mailers to figure out
longway.UUCP...)

[ Judging by the non-standard headers your mailer sent, it's no wonder....
See the next article for std-unix/comp.std.unix posting information.  -mod ]

Maybe you can get a comment from the ANSI committee (X3L2).  It labored
for some years to produce the 8-bit set, which was then accepted lock,
stock and barrel by ISO for 8859/1.  ECMA was an intermediary.

I was following the ANSI deliberations from a distance; as a result the
Prime PT200 was, I think, the first terminal to implement the set.  The
set is something of a compromise.  The ugly inclusion of multiply and
divide amongst the "o"s is particularly weird; originally these
contained the OE diphthongs in deference to the French.  But, to
everyone's surprise, the French didn't want them!

Nobody, but nobody, knows how to design eth and thorn.  If any
Icelanders(?) would post a bitmap AND a PostScript definition of these
four glyphs, many of us would be grateful.

And there IS a standard way of invoking 8-bit characters in a 7-bit
environment: use Shift-out and Shift-in.  These are control-N and
control-O respectively; they can't be typed directly in EMACS and would
confuse any software that assumes <one byte> = <one character position>,
but receiving terminals should do the right thing.

Assigning graphics to control characters is highly non-standard.

[ As someone just pointed out, apparently there is an obscure standard. -mod ]

IBM and Mac assign graphics to the control-1 set (hex 80 to 9F).  Actually
I wish someone would properly implement the control-1 characters, like
reverse linefeed, halfline up and down, CSI...
   __                   __
  /  )             /   /  )             /
 /  / __   _ o  __/   /--/ __  ________/_) _
/__/ (_(_|/ (__(_(   /__/ / (_/_/ /_/ / \_/_)_

Internet:       [e-mail]
uucp:           {mit-eddie,necntc}!primerd!csss-a.prime.com!brooks

Standard disclaimer applies as appropriate.

Volume-Number: Volume 13, Number 54

From uucp  Fri Apr 15 14:27:40 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA09326; Fri, 15 Apr 88 14:27:40 EDT
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Posting to comp.std.unix/std-unix.
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 15 Apr 88 18:23:26 GMT
Apparently-To: std-unix-archive
Status: O

If you're reading this as comp.std.unix on USENET, to post you just
post as to any newsgroup, and the news software will forward your
submission to the moderator.  Assuming your news software is a) new
enough to have this feature, and b) set up correctly.

To post by mail, as you must if you received this by mail (presumably
as part of the std-unix mailing list), you can submit a message by
mailing it to
    [e-mail]
if your mailer recognizes ARPA Internet style domains, or
    uunet!std-unix
if you have to deal with old-style UUCP source routes.  The UUNET
machine speaks to most of the known world, so I won't include paths
to it here.

This newsgroup/mailing list is moderated, so the moderator (me,
John S. Quarterman) reserves the right to not post any given submission.
This is a technical discussion group, so attacks on companies or
people are not appropriate, nor are flames in general.  It's best
to stick to the general topic, as well:  standards related to the
UNIX operating system.

Requests for subscriptions or deletions, and other non-submissions
have to be mailed, regardless of how you received this article.
The place for such messages is:
    [e-mail]
or
    uunet!std-unix-request

You can also send through longway.tic.com or uunet!longway, but those
are harder to find (e.g., from the Internet, your mail system must
understand nameserver MX records).

The former aliases at sally.utexas.edu or uunet!ut-sally also still
work, but are not recommended at the moment, considering that the
ARPANET IMP that connects sally.utexas.edu to the ARPA Internet is
going to be turned off 1 May 1988, and it's not clear when a connection
to NSFnet will be available.

Volume-Number: Volume 13, Number 55

From uucp  Sun Apr 17 13:49:25 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA07114; Sun, 17 Apr 88 13:49:25 EDT
From: (rja <[e-mail]>
Newsgroups: comp.std.unix
Subject: Eth and Thorn characters
Keywords: Icelandic, Vietnamese, ISO8859/1
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (rja)
Organization: GE-Fanuc North America
Date: 16 Apr 88 18:22:53 GMT
Apparently-To: std-unix-archive
Status: O

From: [e-mail] (rja)

  There have been a flurry of postings (primarily in comp.std.unix)
about ISO 8859/1 (8 bit character set for western European languages).

A recent posting has inquired about what the Eth and Thorn characters
look like.

Eth is similar in appearance to the letter D.  However, eth has an additional
horizontal line about halfway vertically up on the left-hand vertical stroke.
This horizontal line extends to the left of where a D would stop and goes
halfway between the curved and vertical strokes of the D.  The horizontal
stroke is symmetric with respect to the vertical left-hand line of a D.

Lowercase eth follows the same pattern with respect to the d, except that
the horixontal line is about 3/4 up the vertical line of a "d".  The line
should be halfway between the top of the vertical line and the place where
the round part of the "d" meets the straight part (upper connection).

Thorn upper and lower case follows this same pattern except that replace all
instances of "d" and "D" above with "p" and "P".  The lowercase thorn has
its horizontal line on the stem as part of the descender and the upper case
thorn has its horizontal line on the stem rather than between the intersections
of the straight and vertical lines forming the top of the "P".

While these characters are originally Icelandic/Norse, the Eth characters are
also used in Vietnamese (Quoc Ngu).  Vietnamese is normally written using a
Roman-style script that has an amasing number of diacritical marks, so it isn't
quite handled by ISO 8859/1.  ISO 8859/1 does come close though....

  I haven't any reasonable way to generate a bit-map or Postscript image, but
these descriptions should get the general idea across to the folks at Prime,
DEC, etc. so they can implement them.

 I'd be interested in getting mail from anyone who knows if a standard character
set exists for Vietnamese.

______________________________________________________________________________
         [e-mail]      or      ...uunet!virginia!edison!rja
             "Noalias must go, this is non-negotiable."  DMR
______________________________________________________________________________

Volume-Number: Volume 13, Number 56

From uucp  Sun Apr 17 16:11:40 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA10753; Sun, 17 Apr 88 16:11:40 EDT
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End of Volume 13
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 17 Apr 88 19:46:02 GMT
Apparently-To: std-unix-archive
Status: RO

This is the last article in Volume 13 of comp.std.unix.
Volume 14 will start immediately.

Volume-Number: Volume 13, Number 57