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

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

From news  Sun Sep 21 21:54:25 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix Volume 7
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 22 Sep 86 02:54:09 GMT
Draft-9: mod.std.unix

This is the first article in Volume 7 of the USENET newsgroup mod.std.unix
(also known as the ARPA Internet mailing list [e-mail]).
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.

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


This newsgroup and mailing list are for discussions of UNIX standards,
particularly the IEEE 1003.1 Trial Use Standard.  The moderator is
John S. Quarterman, who is also the institutional representative of
the USENIX Association to the IEEE P1003 Portable Operating System for
Computer Environments Committee (commonly known as the UNIX Standards
Committee).

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

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

Archives may be found on sally.utexas.edu.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
as ~ftp/pub/mod.std.unix, while the previous volumes may be retrieved
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc., through 6.
The volume with the AT&T public domain getopt(3) is ~ftp/pub/mod.std.unix.v3.

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

Volume-Number: Volume 7, Number 1

From news  Sun Sep 21 22:01:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix and P1003
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 22 Sep 86 03:01:40 GMT
Draft-9: mod.std.unix

This article is a slightly adapted copy of an earlier one.

There seems to be widespread confusion as to the relation of the
newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the
IEEE P1003 standards committee and its subcommittees.  Allow me
to try to clear some of it up.


Because something is discussed in mod.std.unix does not mean that
it is automatically proposed to P1003 for inclusion in the standard.
Proposals to the committee have to be more formal.  Especially they
have to include specific proposed wording.

As it happens, the moderator of the newsgroup is also the USENIX
representative to the committee.  As such, I am willing to present
proposals to the committee if someone actually has some to present.
However, the proposer has to specifically request that for a specific
proposal and I have to agree to it before it will happen.

It is true that several committee members follow the newsgroup and
that I make sure that copies of articles from the newsgroup go to
appropriate technical reviewers or are mentioned to the committee
as a whole.  However, they are not presented as proposals:  they
are presented as comments.  They may help committee members understand
the context of a topic which is treated in the standards document,
but they are unlikely to cause new topics to be added to the document.

This is not to say that input from the newsgroup is not useful
to the committee.  A number of problems with the latest drafts
were pointed out in the newsgroup and fixed because of that.
The time zone discussion has led to an actual proposal which
may be adopted by the committee.


Because something is discussed in mod.std.unix does not even
necessarily mean that it has anything to do with the P1003 committee.


The committee is very aware that they should not be introducing
new facilities.  It has happened a few times.  The only one
I can think of at the moment is file locking, specifically the
mandatory locking feature of flock (which was actually introduced
by the /usr/group committee).  This is also, not coincidentally,
one of the most controversial things in the current document,
even though its proponents only back it because they are convinced
it is necessary.

You will find things in the draft standard document which do not
correspond to your local system, regardless of what your local system
is.  This is because in the real world there are at least two major
variants of UNIX and many minor ones.  To pick one and standardize on
it alone would be to try to outlaw all the others.  This is probably
not even possible, even if it were desirable.  The committee has chosen
instead to try to produce something which is not exactly like anything
out there but which can be implemented with relatively minor changes on
most existing systems.

Ritual disclaimer:  this article is constructed of my personal opinions
and does not necessarily represent any official position of IEEE, P1003,
USENIX, /usr/group, or any other organization.

Volume-Number: Volume 7, Number 2

From news  Sun Sep 21 22:10:19 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 22 Sep 86 03:09:53 GMT
Draft-9: time_t TZ

[ I believe this is from Mark Crispin.  -mod ]

From: @SUMEX-AIM.ARPA:MRC@PANDA
Date: Mon 15 Sep 86 10:32:48-PDT
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: [phone]

Has anyone taken the effort to see how other operating systems handle
this problem?  If not, I'll throw one example I'm quite familiar with
into the pot.

TOPS-20 uses a 36-bit value for the time (after all it runs on a 36-bit
machine).  This is a fixed point number with the decimal point located
between the halfwords expressing the number of days since midnight, 17
November 1858.  Time -1 is reserved to mean "current time", therefore
the latest representable time on TOPS-20 is 7 August 2576, one second
before midnight.  I guess sometime in August 2576 we'll have to fix
TOPS-20 to add another word to the time!  All this is in GMT, by the
way, with no adjustments for leap seconds.

Local time is strictly a user interface consideration.  The default
routines use the following cells to determine how to present the time:
TIMZON    The number of hours local time lags GMT.  +12 and -12 are the
    same zone on different sides of the International Date Line
DSTFLG    Daylight Saving Time flag:
        NEVDST    never use Daylight Saving Time
        ALLDST    always use Daylight Saving Time
        0    use algorithm

DSTBGN    The year in which the algorithm became effective

DSTON    The last day of the year on which DST may start

DSTOFF    The last day of the year on which DST may end

The present algorithm starts on the Sunday preceeding DSTON and ends
on the Sunday preceeding DSTOFF.  It started in 1975, so it makes no
attempt to handle the energy conservation rules of earlier years.

The user interface will accept times in which no zone is specified
("GMT" or "PST" or "PDT", etc. will always override the TIMZON and
DST flags) and convert them into the GMT representation.  Times are
output in the "current local timezone/DST" according to the rules
unless written otherwise.

This is all pretty minimal stuff.  I think Unix should bite the bullet
and use at least a 48 bit time representation.
-------

Volume-Number: Volume 7, Number 3

From news  Sun Sep 28 15:23:02 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: brief notes on the Palo Alto P1003 meeting
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 28 Sep 86 20:22:47 GMT
Draft-9: P1003.Palo.Alto

P1003.1 met week before last (17-19 September) in Palo Alto.
Various technical issues were addressed (many in the form of
line by line objections from the balloting this spring) and
some of them will probably be posted to this newsgroup.

The new secretary is Shane McCarron of MECC and the new keeper of
the document is Hal Jespersen of Amdahl.  (Many thanks to their
predecessors, Steve Head of HP and Jim McGinness of DEC.)

P1003.2 (shell interface) and P1003.3 (verficiation) also met
the same week, as did the /usr/group Real Time working group,
and other /usr/group committees.  I solicit reports from their
secretaries or comments from attendees.

The relations of the GM, /usr/group, and P1003.1 subcommittees
on Real Time were of sufficient interest to me that I took some
notes which I intend to turn into a brief report next time I'm
in town long enough.

The proposal form that you've all seen before as the last section
of RFC.001, but with some of the error code details and X3J11 text
filled in, has been assigned a proposal number and is now P.55.
I will post the complete text shortly.  No action was taken on
including it in the actual document because another proposal on
timezones is expected imminently from HP and I did not feel it
appropriate to push the issue before the other proposal could
be seen.  Presumably, some action will be taken at the next meeting.

Meanwhile, many people at the various meetings got tired of
hearing me say that mod.std.unix != mod.timezone and have
promised to submit interesting articles on new subjects.
How about termios?  Job control?  Real time?  Reliable signals?
High performance file systems?  Atomicity of readdir()?
Appendix H (which is no longer in the draft document)?
Multiple groups?  DoD (and other) security requirements?
Relation of 1003.1 to X3J11?

Volume-Number: Volume 7, Number 4

From news  Sun Sep 28 16:23:04 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: 1003.1 Appendix H.  Additional System Characteristics
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 28 Sep 86 21:22:47 GMT
Draft-9: 2.9

The POSIX(TM) Trial Use Standard has attached to it an Appendix H
whose purpose was to include parameters not in <limits.h> but
that might be of use to an application porter in determining
how well or if an application would run on a target system.

This appendix was removed from the working document at the Palo
Alto meeting of the working group on the grounds that while
a guide of this type for the application porter might well
be useful, Appendix H is not it.  This is because the information
it requests is too arbitrary, too vague, and it was written by
representatives of vendors, not users.

A committee of representatives of users was appointed to produce
a proposal for a replacement appendix.  It occurs to me that there
are a lot of users on USENET.  It would be interesting to gather
comments on what should be in the new appendix.

A couple of caveats:  I am not on the subcommittee just mentioned,
and they are under no obligation to pay attention to anything that
appears here.  And minor modifications to the previous appendix
are not what is wanted:  a plan for a complete new set of implementation
characteristics is needed.  Given those constraints, I suspect someone
out there may still be able to make useful suggestions.

Since Appendix H is an appendix and not part of the Trial Use Standard
proper, I am permitted to post it to the network.  Here is its full text
as it was before it was removed in Palo Alto:





                     H.  Additional System Characteristics

          In the header file <limits.h> we have placed parameters that
          may  vary  from  system  to  system  and  need to be used by
          applications in a dynamic fashion.  There is also a  set  of
          parameters  that  can  influence  how an application program
          runs (or if it will run) which are not  dynamic  application
          parameters,   but   may   be   essential   in   matching  an
          implementation  and  application  to  make  sure  they  work
          together.

          Should conforming implementations  be  required  to  provide
          this in printed form on a product model basis?  Should it be
          recommended  that  application  implementors   define   what
          parameters  from  this  list impact the ability to run their
          application?

          This  would  eventually  go  into  the  definitions  section
          (Ch. 2)  or  perhaps a section of its own. Feedback on these
          items is sought in the trial use period to  determine  which
          are  considered  to  be  of  use  in determining application
          portability and capacity.

          H.1  Conforming implementation characteristics

          In addition to the parameters specified in the  header  file
          <limits.h>,  the  following information shall be provided to
          more clearly describe a conforming implementation.   Vendors
          of   conforming   applications   should  provide  a  similar
          description   indicating   the   required   and    preferred
          characteristics  of  an  implementation  that  might  use an
          application.  Such a specification might include  how  these
          parameters  need  to  vary  as  application  use varies (for
          example, with increase in the number of users, in the number
          of  records,  or  in  the transaction rates).  Some of these
          characteristics are simple numbers, others  may  be  in  the
          control  of  a  system  manager  within  limits and some may
          differ within limits of hardware configurations.  In all  of
          these  cases  the  limits  shall  be described.  In any case
          there are no specified range of values for these  parameters
          required  by  this standard.  Some of these limit values may
          be mutually exclusive for a given implementation or product.

          Is sizeof(int)=sizeof(ptr)?

          Maximum number of users logged in at one time
          Maximum number of user IDs
          Maximum number of active processes
          Maximum number of processes connected by a pipe

          Maximum number of groups
          Maximum number of users in a group

          Maximum number of hours until clock rollover



          H.1 Conforming implementation characteristics              1

          IEEE Std 1003.1       POSIX Appendix H    Trial Use Standard


          Calendar date/time when calendar rollover occurs

          Maximum number of serial ports
          Number of ports that support Modem Control
          Maximum bit rate per serial port
          Maximum aggregate character input rate
          Maximum aggregate character output rate
          Maximum aggregate character input & output rate

          Maximum number of directories
          Maximum number of levels of directory nesting
          Maximum number of files per logical volume
          Maximum number of logical volumes concurrently mounted

          Maximum number of locks per logical volume
          Maximum number of locks active at one time
          Maximum number of files that can be opened concurrently
          Maximum number of files a process can open concurrently

          Maximum logical file size
          Maximum physical file size
          Maximum logical volume size
          Maximum physical disk capacity (multi-spindles)

          Maximum delay in writting modified buffers to disk

          Minimum disk storage occupied by OS & essential tools
          Maximum disk storage occupied by OS including tools

          Implementation supports swapping of processes?
          Implementation supports virtual memory paging?

          Maximum physical memory capacity
          Maximum physical memory address space per process
          Maximum logical address space per process
          Maximum text/instruction address space per process
          Can text/instruction address space be shared?
          Maximum local data space per process
          Maximum size for a single array in bytes
          Maximum global (shared) data space per process
          Maximum stack space per process

          Minimum RAM used by resident OS kernel
          Maximum RAM used by resident OS kernel

          Maximum number of characters significant in external C
                  variable and procedure names
          Internal character representation (ASCII,...)
          Number of bits used for internal character storage
          Number of bits/character permitted in string I/O
          Number of bits/character permitted in file names

          Floating point format (IEEE, other)
          Floating point mantissa range



          H.1 Conforming implementation characteristics              2

          IEEE Std 1003.1       POSIX Appendix H    Trial Use Standard


          Floating point exponent range

          Number of bits per register
          Number of registers that can be assigned to pointer variables
          Number of registers that can be assigned to short variables
          Number of registers that can be assigned to integer variables
          Number of registers that can be assigned to long variables
          Number of registers that can be assigned to float variables
          Number of registers that can be assigned to double variables

          Media classes supported:
          1/2 in. tape, 9 track, 1600 bpi
          1/2 in. tape, 9 track, 6250 bpi
          Qic-11, 1/4 in. streamer tape
          Qic-24, 1/4 in. streamer tape
          5.25 inch floppy, 8 512-byte sectors/track, 96 tpi
          5.25 inch floppy, 8 512-byte sectors/track, 48 tpi

          Some number of these  questions  are  configuration-specific
          and  may  vary  dynamically  in  execution  (for instance, a
          system has a theoretical maximum disk storage  capacity,  at
          execution  it  has some maximum of connected storage, and at
          any point in time  the  maximum  amount  available  that  is
          mounted  is  in  flux).   This  may call for three levels of
          specifying some of this data:

          1.  Published theoretical maximum values

          2.  Static configuration files that may be read and
          interpreted by an executing program

          3. System calls that provide dynamic snapshots of key
          information.

          Please provide feedback on which of these  may  require  the
          second or third form of description.



















          H.1 Conforming implementation characteristics              3

Volume-Number: Volume 7, Number 5

From news  Mon Sep 29 13:48:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Problem in "tar" definition in P1003
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 29 Sep 86 18:47:59 GMT
Draft-9: 10.0

From: hoptoad![e-mail] (John Gilmore)
To: [e-mail]
Cc: sun!amdahl![e-mail]
Date: Mon, 29 Sep 86 03:48:59 PDT

In the version of P1003 that I have (long before the Trial Use Standard,
since IEEE would rather make money than give it widespread distribution
in the Unix community) there is a problem with the tar format described.

[ I'd be interested to know how much they're making, but at less than $20
per 200 page hardback, I doubt it's much.  Also, remember that they've got
not only the costs of publication and distribution of the book itself to
pay for but also those of the reams of drafts, proposals, RFCs, and random
verbiage that get mailed around to everybody on the interest list.  -mod ]

Basically it is the same as V7 tar with some new types added for directories,
devices, named pipes, etc.  It also has some of the unused space in
the header blocks filled with owner name, group name, etc.  All good ideas.

Anyway, the problem is that directories are defined as a new file type
(linktype).  This works OK when talking to another P1003 "tar" program,
but I implemented it and tried it.  If you feed such a tape to a V7 or
4BSD tar program, it doesn't recognize the linktype, so it creates the
directory as a normal [empty] file.  This causes all the files that
should have gone into that directory to fail because the directory name
is now in use as a file name.  (I'm sure Sys V tar has the same problem.)

The temporary workaround I am using is to write the tapes with a linktype
of "directory" and a trailing slash in the file name.  This causes 4.2
to create it as a directory and causes V7 to fail at trying to create it
as a file.

I suggest that we change the "tar" format in the standard.  To what I
am not sure.  Maybe the above kludge is good enough.  Maybe we should go
back to the 4.2BSD style tar tape.

I also suggest that we actually implement and run a few of the other
"innovations" of this standard, before we standardize it...

[ Good idea.  Such things as Doug Gwyn's mkdir/rmdir implementation
are quite useful, especially when distributed for general use.  -mod ]

    John

PS:  I was on the APL Standards committee and there is always a strong
temptation to "fix" things rather than embed mistakes in concrete.
Resist!  The mistakes are already embedded, in user programs and file systems
and minds...

[ The committee is aware of that problem.  -mod ]

PPS:  Post the **&^&^$%#@ standard to the net!  This message needs to be
repeated until the bozo(s) who are preventing it get the message.  I'm sure
they are having lots of fun passing drafts back and forth via email while
we sit out here empty handed.

[ Not true.  The committee in general doesn't have machine-readable text
of the document, either (only the few people actually preparing the new
draft do):  it's IEEE, not the committee, that has imposed the current
moratorium on distributing text that "represents" (as they insist we
put it) the current document.  As I understand it, the restriction
applies only to actual Standards (whether Trial Use or Full Use).
I.e., it is likely that the draft between them will be available
by the previous mechanisms (anonymous FTP on the Internet and UUCP
from designated machines).

The Appendix I just posted was taken from the on-line copy of Draft 6
and I typed in changes found in the published book of the Trial Use Standard
(once known as Draft 7):  I don't have an on-line copy of the latter, either.

As the person responsible for distributing machine-readable text
representing previous drafts, I can assure you that *nobody* *ever*
passed them around by electronic mail:  think of the size of the thing!

Finally, it's not as if the document weren't publicly available.
Less heat and more light please:  this is a technical newsgroup,
not a shouting match.
-mod ]

Volume-Number: Volume 7, Number 6

From news  Mon Sep 29 13:52:45 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Summary of Volume 6 of mod.std.unix
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 29 Sep 86 18:52:17 GMT
Draft-9: mod.std.unix

Administrativia:    N1, N13b, N51
mod.std.unix & P1003:    N2
Publicity:        N6
Access to standards:  N7, N10, N11, N12, N13a, N21, N22, N26, N27, N40, N46, N50
Access to user groups and publications:  N11, N21, N40, N45
POSIX Conformance Workshop:    N20
P1003.2 Shell Working Group:    N24, N25 (Hal Jespersen)
IEEE 1003.1, POSIX, & ISO/TC97:    N49 (Isaak)
RFCs:            N16 (jbc, jsq)

write EOF:        N5, N8, N9
tape file marks:    N14
ioctl vs. iocntl (and fcntl):  N15 (Smith, jbc), N17 (jbc), N18 (rbj), N19 (dag)
mkdir & rmdir implementation:  N23 (jsq, dag), N28 (dag)

Timezones:
    motivation:  N3 (Horton); location:  N4 (dag);  past:  N4 (jsq)

RFC.001:  Timezones:  N29 (jsq)
    RFC.001 Summary of mod.std.unix Volume 5:  N30 (jsq)
    RFC.001 Timezone Interface:  N31 (Elz)
    RFC.001 Timezone Examples:  N32 (Olsen)
    RFC.001 Timezone Proposal:  N33 (jsq)

Responses to RFC.001:
    Previous call on settz():  N34 (Noel), N36 (Elz)       (perhaps add)
    Implementor's TZ a bad default:  N34 (Noel), N36 (Elz)          (add note)
    Method to retrieve TZ name:  N34 (Noel), N36 (Elz)      (not tzname[])
    BSD timezone():  N34 (Noel)
    tzset() of System V:  N34 (Noel), N36 (Elz)      (implement, don't add)
    TZ & DST rule:  N34 (Noel), N35 (Horton), N36 (Elz)(can't be done right)
    Details of Olsen's implementation:  N37 (Devine)
The parenthetical comments at the far right indicate my interpretation
of the outcome of the discussions on the various topics and what I
recommended the committee do.

What does time_t represent and localtime() convert?  N38 (Harris)
*    unsigned for future:  N39 (Franklin), N42 (Harris), N43 (Yao)
    signed for past:  N41 (Olsen)
    an implementation:  N44 (Campbell)

Far Past:  N46 (jsq)
*    different representation:  N44 (jsq, genealogy), N47 (Horton)
    use time_t:  N48 (Brader)

* indicates the side of the discussion that won, as I see it.

Abbreviations:
    Brader:        Mark Brader
    Campbell:    Larry Campbell
    dag:        Douglas A. Gwyn
    Devine:        Bob Devine
    Elz:        Robert Elz
    Franklin:    Dan Franklin
    Harris:        Guy Harris
    Horton:        Mark Horton
    Isaak:        James Isaak (P1003 co-chair)
    jbc:        John B. Chambers (guest moderator)
    Jespersen:    Hal Jespersen (P1003.2 co-chair)
    jsq:        John S. Quarterman (moderator)
    Noel:        Greg Noel
    Olsen:        Arthur Olsen
    rbj:        Root Boy Jim Cottrell
    Smith:        Roy Smith
    Yao:        Joe Yao

Volume-Number: Volume 7, Number 7

From news  Mon Sep 29 14:14:39 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: IEEE 1003.1 P.55
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 29 Sep 86 19:14:18 GMT
Draft-9: TZ.P.055

There are several decisions needed regarding timezones and 1003.1:

Which proposal should be accepted (P.55 or the one forthcoming from HP)?

If P.55:
Accept settz 4.5.3?
Add 4.5.4 or incorporate third paragraph in 4.5.3?
Details of Errors and References.
Suggested Appendices:
    Olsen's implementation?
    List of names of timezones?

The rest of this article is the text of Proposal 55.

IEEE 1003.1 P.55:

Time Zone Proposal based on work by Robert Elz and Arthur Olsen.
Submitted by John S. Quarterman.  Proposal number assigned 19 Sept. 1986.

Add 4.5.3 and 4.5.4 to the standard and perhaps also
document Arthur Olsen's implementation in an Appendix.

Note that all of 4.5.4 except the last paragraph of 4.5.4.2, the last
sentence of 4.5.4.3, and all of 4.5.4.4 and 4.5.4.5, is intended to
track X3J11.  I.e., the purpose of 4.5.4 is to constrain ctime() and
localtime() further than X3J11, not to change what X3J11 says about them.

% is used to indicate the section sign.  Italics are implied in the
normal format of the POSIX document.


4.5.3    Set Local Time Conversion
Function:  settz()

4.5.3.1    Synopsis
    int settz(p)
    char *p;

4.5.3.2    Description
    The settz() function determines the conversion from GMT
of the local times returned by localtime() and ctime().
When called with a NULL pointer argument (p==0), settz
shall select the appropriate local time conversion for the
location of the host machine on which the call is executed.
When called with a null string (p!=0 && *p=='\0'), settz
shall select no conversion for localtime, making localtime()
and gmtime() equivalent and ctime() and asctime(gmtime())
equivalent.  When called with a non-null string (p!=0 && *p!='\0'),
settz may set the conversion according to that string.
The format of the string and the conversions it may specify
are implementation specific.  If an implementation accepts
non-null string arguments to settz, the implementation
should allow users to define their own conversions
rather than restricting conversions to a standard set.
If settz is called with a string for which the implementation
can not find a conversion, settz shall return -1, but the
conversion it sets is implementation defined and may be one of
GMT, the executing machine's local time, or local time for
the area where the implementation was performed.

4.5.3.3    Returns
    Upon successful completion, settz() returns 0, otherwise -1,
and errno is set to indicate the error.

4.5.3.4  Errors
    If the function returns -1 the value stored in errno may be
interpreted as follows:

[EFAULT]    The argument p points outside the process's allocated
    addresss space.

4.5.3.5  References
time() %4.5.1, localtime(), ctime() %4.5.4.


4.5.4  Get Local Time
Functions:  localtime(), ctime()

4.5.4.1  Synopsis
    #include <time.h>

    struct tm *localtime(timer)
    char *ctime(timer)
    time_t *timer;

4.5.4.2  Description
    The localtime() function converts the calendar time pointed to
by timer to local time in the form of a string.  It is equivalent to
    asctime(localtime(timer))

    The local time conversion is specified by a call on settz().
If localtime() or ctime() is called and settz() has not been called
since the last exec(), the localtime() or ctime() call shall call
settz(getenv("TZ")) before performing the local time conversion.
The local time conversion should be accurate for all times
from the base time of the time() function up to the time
the call is made.  Future times should be converted as accurately
as possible with available political information.  Daylight savings
time should be taken into account in both cases.

4.5.4.3  Returns
    The localtime() function returns a pointer to that object.
    The ctime() function returns the pointer returned by the
asctime() function with that broken-down time as argument.
    On unsuccessful completion of either function, a NULL pointer
shall be returned and errno is set to indicate the error.

4.5.4.4  Errors
    If either function returns a NULL pointer the value stored in
errno may be interpreted as follows:

[EFAULT]    The argument points outside the process's allocated
    address space.

4.5.4.5  References
time() %4.5.1, settz() %4.5.3.

Volume-Number: Volume 7, Number 8

From news  Tue Sep 30 11:04:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003.2 Command Suites
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 30 Sep 86 16:03:31 GMT
Draft-9: P1003.2.Command.Groups

From: nike!pyramid!amdahl![e-mail] (Hal Jespersen)
Date: Mon, 29 Sep 86 13:06:16 PDT

Here is a subject != timezones.
[ Much appreciated, for sure.  -mod ]

The P1003.2 Shell and Utilities Working Group is currently soliciting
input for proposed commands to be included in the standard.  It is felt
by the Working Group that these commands should be grouped into
"command suites" that would not have to be implemented by all
conforming implementations [as long as the implementations identified
which suites were there, of course].  This is similar to the
organization of AT&T's SVID, where commands are divided into
"extensions".

Three companies at the September Palo Alto meeting promised to submit
RFCs on proposed suite names and the contents of each suite, by command
name.  One of these was AT&T, who will submit the SVID organization.

In the meantime, does anyone have suggestions on which commands to
include and how to organize them?  Remember that the charter of the
Working Group generally limits the commands to:

    commands usefully executable via the shell by application
    programs or shell scripts (i.e., not terminal interface
    programs, or window managers, etc.)

    user-level, and not system administrative, commands.

If you have a detailed proposal to submit to the Working Group, contact
me or:

    Don Cragun
    Sun Microsystems, Inc.
    2550 Garcia Avenue
    Mountain View, CA  94043
    [phone]
    {amdahl|decvax|hplabs|ihnp4|seismo}!sun!dwc

Thanks for your input.

                Hal Jespersen
                [phone]
                ...{ihnp4|hplabs|seismo|decwrl}!amdahl!hlj
                Amdahl Corporation
                Mailstop 316
                1250 East Arques Avenue
                Sunnyvale, CA 94088-3470

Volume-Number: Volume 7, Number 9

From news  Tue Sep 30 11:11:26 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: IEEE 1003.1 P.55
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 30 Sep 86 16:11:06 GMT
Draft-9: TZ.P.055

From: seismo!elsie!ado (Arthur Olson)
Date: Mon, 29 Sep 86 22:46:41 EDT

A few words regarding the "P.55" time zone proposal.

One thing it lacks is a way of determining the "time zone abbreviation"
("EST" or "EDT" or "EWT", for example) to be used with a particular combination
of time and time zone.  One approach is to declare a global variable such as
    char *    tz_abbr;
and have "localtime" set it to point to the abbreviation for the converted time.
Alternately, some folks have suggested adding either a character pointer or a
character array to the "struct tm" that "localtime" returns as a way of
recording the abbreviation.  The approach used isn't too important;
standardizing the approach is.  (Avoiding changes to the "struct tm" structure
would be desirable if there are applications that have stored such structures
in files.  I don't know of--and can't imagine--applications that do so.)

If the standard *does* end up telling how a caller of localtime can learn the
abbreviation for the converted time, then a change may be needed in the
passage reading

> When called with a null string (p!=0 && *p=='\0'), settz
> shall select no conversion for localtime, making localtime()
> and gmtime() equivalent and ctime() and asctime(gmtime())
> equivalent.

If, for example, "localtime" sets "tz_abbr" as a side effect, but "gmtime"
doesn't, then calling "localtime" and calling "gmtime" can never be equivalent.

It may be simplest to just leave the settz("") case out of the standard
entirely--any application programmer who's interested in getting GMT can
just call gmtime() directly.  (The settz("") case is actually a bone to throw
to speedsters who don't want "ls" to get time conversion information from
disk; while this has some value, the value may well be too small to warrant
standardization.)  But having settz((char *) 0) set things for local time
(regardless, for example, of the state of the environment variable "TZ")
provides a capability that's important to programs such as uucp;
the behavior of settz((char *) 0) *should*, I believe, be documented.

Concretely:  I'd suggest this shortening of section 4.5.3.2:
    4.5.3.2    Description
    The settz() function determines the conversion from GMT
    of the local times returned by localtime() and ctime().
    When called with a null pointer argument (p==0), settz
    shall select the appropriate local time conversion for the
    location of the host machine on which the call is executed.
    When called with a non-null pointer argument (p!=0),
    settz may set the conversion according to that string...

And, perhaps, an addition along these lines to 4.5.4.3 (or wherever):
    As a side effect, both ctime and localtime set the global character
    pointer tz_abbr to point to the time zone abbreviation for the
    converted time and time zone.
--
    UUCP: ..decvax!seismo!elsie!ado   ARPA: elsie![e-mail]
    DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.

Volume-Number: Volume 7, Number 10

From news  Thu Oct  2 01:59:24 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 2 Oct 86 06:59:13 GMT
Draft-9: 2.3.folding

Date: Mon, 29 Sep 86 12:33:36 edt
From: [e-mail] (Mark Horton)

OK, here's a new topic.  File names.

I note that the committee recently decided that all file names
in conforming systems must be case sensitive, for example,
makefile and Makefile must be different files.  (I've forgotten
where I read this, it was probably Communixations.)

I think this is a mistake.  UNIX is the only major operating system
that treats things like file names, logins, host names, and commands
as case sensitive.  The net effect of this is that users get
confused, since they have to get the capitalization right every time.
To avoid confusion, everybody always just uses lower case.  So
there are few, if any, benefits from a two-case system, and any time
anyone tries to do something that isn't pure lower case, it causes
confusion for somebody and often breaks some program.

Another problem is that emulations on other operating systems,
such as VMS or MS DOS, will become impossible without drastic
changes to their file systems.  Given the problems in the above
paragraph, plus politics as usual, I think it is unlikely that
other systems will be changed to have case sensitive file systems.
After all, it's not like it was easiest to make the VMS filesystem
case insensitive - that took extra effort on their part.

I think it's a mistake to move in the direction of requiring other
operating systems to become case sensitive.  If anything, motion in
the other direction might be of more benefit.

Note: I am NOT suggesting that UNIX should have a case insensitive
filesystem that maps everything to UPPER CASE like MS DOS.  There is
nothing wrong with mapping everything to lower case, for example.
It's also reasonable to leave the case alone, but ignore case in
comparisons.  There is also probably a good argument for keeping
it case sensitive (after all, there are probably 5 or 6 people out
there who really need both makefile and Makefile, or both mail and
Mail, for some reason that escapes me at the moment.)  But I think
it would be a mistake to require other systems to change if they
are to support a POSIX emulation on top of them.  (On the other hand,
it may be reasonable to expect other operating systems to support
more general file name lengths and character sets, rather than things
like the MS DOS 8+3 convention.  But in practice, this may be too
painful to fix.)

    Mark Horton

Volume-Number: Volume 7, Number 11

From news  Thu Oct  2 11:08:33 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 2 Oct 86 16:08:21 GMT
Draft-9: 2.3.folding

Date: Thu 2 Oct 86 01:59:26-PDT
From: Mark Crispin <[e-mail]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: [phone]

I would like to add a loud "Bravo!" to Mark Horton's message!  The present
case sensitivity of the Unix filesystem is a real drag, and something that
has regularly and reliably caused me problems when working in a heterogenous
environment.  As far as I can tell, the only individuals who actually *like*
case sensitivity in Unix are the high-schoolish hackers who think it's really
cute to write programs with separate -1, -l, -I, and -L switches.

I think that the most reasonable proposal is to do a free case match on input,
so that "more foobar" is the same as "More FooBar", etc.  On output, you first
do a free case match to see if there is an extant file and if so preserve the
case of that file.  In other words, if I overwrite FooBar but specify foobar
or FOOBAR, the file is still called FooBar.  Otherwise, use whatever case the
user specifies.  Renaming would always use the case the user specifies, so the
user can rename foobar to FooBar, etc.

Now, if I can convince you guys to do this for usernames, I will take back at
least 50% of the nasty things I've ever said about Unix.  Golly gee, it would
be nice to be MRC or Crispin, not "mrc" or "crispin"...

Another way of doing it is how TOPS-20 does it.  TOPS-20's filesystem isn't
*really* case independent.  All lowercase characters are coerced into upper
case, so if I say foobar.txt it becomes FOOBAR.TXT in the actual filename.
This is both from the user interface and from the filename lookup system call.
It is, however, possible for any of the 128 ASCII characters to be in a filename,
provided that the "oddball" characters are quoted using CTRL/V.  In other words,
a FooBar.Txt file is possible on TOPS-20, but only by F<^V>o<^V>oB<^V>a<^V>r.T<^V>x<^V>t.

For once, I don't favor the TOPS-20 way of doing things.  TOPS-20's scheme is
alright if you started with case independence to begin with, but I don't think
it would fit in well into Unix, and certainly not without a major flag day.  I
hope that my suggestion above could fit in with only minimal inconvenience.

I found on TOPS-20 that no serious user used case-sensitive filenames.  Everybody
appreciated the case-insensitivity of the interface, even though it took the form
of coercing to upper case.  My experience also suggests that case sensitivity is
a pain in the a**; I tried writing a major utility in Interlisp using mixed case
function and variable names and eventually gave up when most of my errors turned
out to be case errors.  It's *so* much easier to keep the shift lock key down...

-- Mark --
-------

Volume-Number: Volume 7, Number 12

From news  Fri Oct  3 12:11:46 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: IEEE 1003.1 P.55
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 3 Oct 86 17:11:33 GMT
Draft-9: TZ.P.055

From: seismo!decvax!ittatc!bunker!garys (Gary Samuelson)
Date: Wed, 1 Oct 86 11:04:08 edt
Organization: Bunker Ramo, Trumbull CT

In article <[e-mail]> you write:
>If settz is called with a string for which the implementation
>can not find a conversion, settz shall return -1...

Under section 4.5.3.4, the appropriate value for errno is not
specified for this case.  See suggested additional wording, below.

>4.5.3.4  Errors
>    If the function returns -1 the value stored in errno may be
>interpreted as follows:

I suggest the following change in wording:

-[EFAULT]    The argument p points outside the process's allocated
-    address space.

+[EFAULT]    The argument p does not point to a readable string.

This covers the case where the beginning of the string is within
the process's address space, but the end is not.

I suggest the following additional wording:

+[EINVAL]    The argument p points to a string for which the
+    implementation could not find a conversion.

>4.5.4  Get Local Time
>Functions:  localtime(), ctime()
>
>4.5.4.1  Synopsis
>    #include <time.h>

It is not clear that the type of 'timer' specified for 'ctime'
also applies to 'localtime'.  I suggest the following additional
wording:

>    struct tm *localtime(timer)
+    time_t *timer;
+
>    char *ctime(timer)
>    time_t *timer;

>4.5.4.3  Returns

The description of ctime's return value specifies not only the return
value of ctime, but also how ctime should be coded (i.e., 'ctime' must
call 'asctime').  I suggest the following change in wording:

-    The ctime() function returns the pointer returned by the
-asctime() function with that broken-down time as argument.

+    The ctime() function returns a pointer to a string containing
+the time, converted to the same format produced by 'asctime'.

>4.5.4.4  Errors

I suggest the following change in wording:

-[EFAULT]    The argument p points outside the process's allocated
-    address space.

+[EFAULT]    The argument p does not point to a readable object of
+    type time_t.

This covers the cases where the first byte of time_t is in the address
space, but the last byte isn't, and where the pointer is not properly
aligned.

I suggest the following additional wording:

+[EINVAL]    The argument points to an object which does not contain
+    a valid time_t value.

Gary Samuelson


Volume-Number: Volume 7, Number 13

From news  Fri Oct  3 12:56:36 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re:  Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 3 Oct 86 17:56:07 GMT
Draft-9: 2.3.folding

Date:     Thu, 2 Oct 86 12:43:49 EDT
From: Dan Franklin <im4u![e-mail]>

I can see that it will be hard to emulate POSIX filenames on top of an
operating system such as MS-DOS or VMS, but the benefits of changing the
POSIX spec must be weighed against the costs.  Suppose we changed the spec
so that it permitted a POSIX implementor to provide either a
case-sensitive or case-insensitive filesystem, their choice (which I think
is what Mark is proposing).  There are three groups of people who will be
affected: those who write POSIX emulators, those who write programs for
POSIX, and those who *use* POSIX and its programs.  The last group will be
the largest and most important by far; the emulator writers will be the
smallest group.

So how would users be affected?  It might benefit them, because
case-insensitivity might really be better than case-sensitivity.  However,
in the absence of a controlled study, let's assume the null hypothesis:
that it makes no big difference.  More than "proof by assertion" is needed!

Regardless of which is really better, some users will probably benefit
because they will be used to other operating systems providing
case-insensitivity, particularly MS-DOS.

However, if we really make it an implementor's choice, users will
be hurt by the fact that each POSIX system they encounter will be
different.  In fact, this system-to-system difference will probably
cause more problems than optional case insensitivity would solve.

What about people who write POSIX programs?  They will lose.  To the extent
that POSIX permits two possible underlying filesystems, a truly portable
POSIX program will have to be prepared for either one.  For many programs
it may not matter what the FS looks like, but if it does matter, it will
mean extra work.

Finally, there are all those emulator writers.  They might find it easier;
then again, they might not.  If I were going to do an emulator on top of
MS-DOS, then (since I don't work for Microsoft) I would probably use the
existing filesystem just as a base to build the POSIX filesystem, almost
the way UNIX builds a named hierarchical filesystem space out of inodes.
Going to case insensitivity wouldn't help me a bit, because of the other
limitations Mark mentioned.  It might help Microsoft, because they could
change the 8+3 convention at the same time.  But unless they were willing
to do that, it wouldn't help them either.  VAX-VMS might be easier, but
again there are other problems I would have to solve.  Case-insensitivity
would help me some, but I'd still have a lot of work ahead of me.

But arguments regarding emulator-writing are beside the point.  No matter
what POSIX does on this, it will always be possible to write a POSIX
emulator on top of an existing operating system.  So the ease of *using*
the system must take precedence over the ease of writing it.

For the reasons above, I believe that making case-insensitivity an *option*
would be a bad idea.  Changing the spec to *insist* on case-insensitivity
might be a good idea, but it would cause enough problems w.r.t. existing
UNIX systems that it ought to be very strongly motivated.  To start with:
is it really much easier for people to use such a system?

    Dan Franklin

Volume-Number: Volume 7, Number 14

From news  Fri Oct  3 14:09:18 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 3 Oct 86 19:08:59 GMT
Draft-9: 2.3.folding

Organization: Tektronix, Inc., Beaverton, OR.
Date: 03 Oct 86 11:25:11 PDT (Fri)
From: "David C. Stewart" <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

In article <[e-mail]> Mark Horton <[e-mail]> writes:
>It's also reasonable to leave the case alone, but ignore case in
>comparisons.  There is also probably a good argument for keeping
>it case sensitive (after all, there are probably 5 or 6 people out
>there who really need both makefile and Makefile, or both mail and
>Mail, for some reason that escapes me at the moment.)

    I can think of one well-used exception right away: make(1), as it
works now, will look for rules in `makefile' first, and if `Makefile'
exists in the same directory, it will not be used by make.  On the
other hand, Glenn Fowler's Fourth Generation Make [1] chooses the
opposite order of accepting default rules files, ie, it tries
`Makefile' first and, if one does not exist, it tries `makefile'.
It is claimed that this is a feature, rather than an annoyance since
Fourth Generation makefiles are incompatable with old-style makefiles.
Thus, one can maintain the old make makefile in `makefile' and the new make
makefile in `Makefile'.

    This may just be picking nits, but I think the point is that
case sensitivity in the file system is a Unix feature, like it or
not.  There may be other applications that depend on case-sensitive
file names that would become non-portable.

[1] Fowler, Glenn S., "The Fourth Generation Make", Proceedings of the
Usenix Association Summer Conference, Portland, OR, 1985.  (Note that
the actual release of nmake in the AT&T Toolchest differs in this
respect with the function described in this paper.)

--
David C. Stewart                          uucp:    tektronix!davest
Unix Systems Support Group                csnet:   davest@TEKTRONIX
Tektronix, Inc.                           phone:   [phone]

Volume-Number: Volume 7, Number 15

From news  Fri Oct  3 16:14:27 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 3 Oct 86 21:14:14 GMT
Draft-9: 2.3.folding

Date: Fri, 3 Oct 86 12:26:22 PDT
From: sun!gorodish![e-mail] (Guy Harris)

> From: [e-mail] (Mark Horton)
> Subject: Case sensitive file names

> I think this is a mistake.  UNIX is the only major operating system
> that treats things like file names, logins, host names, and commands
> as case sensitive.

It's been a while since I used Multics; I think it was case-sensitive.  Of
course, I don't know whether it counts as "major" here or not; I don't know
how many sites are around.  Are you sure there are no others?

> It's also reasonable to leave the case alone, but ignore case in
> comparisons.

This would probably be the best scheme (I think the Xerox Alto's operating
system did this).  Some people may want to use mixed case in file names for
aesthetic reasons, for example.

> There is also probably a good argument for keeping it case sensitive
> (after all, there are probably 5 or 6 people out there who really need
> both makefile and Makefile...

This means UNIX probably can't change, at least not without a fair bit of
pain.  I know of at least one directory on a UNIX system that has both
"makefile" and "Makefile" in it; this would cause some upset on a
case-mapping UNIX system.

However, there is another problem with case mapping.  It's dependent on the
language the text is in!  Doing case mapping is all very well and good for
English-speaking users; the algorithm for mapping characters between cases
in English is straightforward.  However, in German "ss" is a single special
character in lower-case but "SS" in upper case.  Even if you don't have
anomalies like this, the current schemes proposed by AT&T for "international
UNIX" use various ISO codes; this means that the character whose hex value
is E6 is the "ae" diaresis in the ISO Latin Alphabet #1, and thus matches
the character whose hex value is C6 (which is the "AE" diaresis); however,
in the JIS C6226 Kanji set, it is probably the first byte of a two-byte
sequence representing a Kanji sysmbol, and I don't think it gets case mapped
at all.

This means that the operating system would have to know what character set a
particular character was in, so that it could map its case correctly; this
would be best done with sequences embedded in the file name indicating
shifts in the character set to which bytes belong.  (These same sequences
should be used in text files, character strings in programs, etc..  Other
suggestions include a per-file character set designator, that would
presumably apply to any files containing character strings, including
directories; however, this means that *all* strings in that file must be in
the same character set, which is not always a reasonable restriction.)  It
would then have to know how to do case mapping for all character sets
supported by the system, and would have to be modified or have new
information supplied to it if a new character set was to be supported.

Volume-Number: Volume 7, Number 16

From news  Sun Oct  5 17:23:30 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 5 Oct 86 22:23:17 GMT
Draft-9: 2.3.folding

Date: Fri, 3 Oct 86 20:07:32 edt
From: Robert Viduya <gatech!gitpyr![e-mail]>

> Date: Mon, 29 Sep 86 12:33:36 edt
> From: [e-mail] (Mark Horton)
> Subject: Case sensitive file names

I've found a useful rule to be used in deciding cases like this is to
decide in favor of the more general and flexible.  A couple of times
I've been guilty of saying, "Well, I can't think of any good reason for
this particular feature, so I'll get rid of it", only to discover,
later on, a good reason for a feature.  I don't believe in artificial
limits mainly because the person who implements the limit generally
hasn't considered ALL possible reasons for going beyond the limit.

> I think this is a mistake.  UNIX is the only major operating system
> that treats things like file names, logins, host names, and commands
> as case sensitive.  The net effect of this is that users get
> confused, since they have to get the capitalization right every time.
> To avoid confusion, everybody always just uses lower case.  So
> there are few, if any, benefits from a two-case system, and any time
> anyone tries to do something that isn't pure lower case, it causes
> confusion for somebody and often breaks some program.

It isn't difficult to explain Unix's case-sensitivity to a user and,
once explained, the case-sensitivity tends to be one of the few things
a user remembers without having to be reminded.  What confusion may be
caused by case-sensitivity is lost in the much greater confusion caused
by trying to learn a new operating system.

> Another problem is that emulations on other operating systems,
> such as VMS or MS DOS, will become impossible without drastic
> changes to their file systems.  Given the problems in the above
> paragraph, plus politics as usual, I think it is unlikely that
> other systems will be changed to have case sensitive file systems.
> After all, it's not like it was easiest to make the VMS filesystem
> case insensitive - that took extra effort on their part.

But, on the other hand, adopting a VMS or MS-DOS filesystem to coexist
with Unix in a Unix environment would be trivial as far as filenames
are concerned.  The fact that Unix allows *any* ascii character in it's
filenames (except for the path seperator, '/', and the string
terminator, NUL), makes it almost ideal for adopting other, foreign
filesystems to it because most of the special graphic characters (!, @, #,
$, and etc..) can already be represented in a filename without having to
be mapped to something else (unlike other, more restrictive, operating
systems).


                robert

---
Robert Viduya                         [e-mail]

Office of Computing Services                    [phone]
Georgia Institute of Technology
Atlanta, Georgia    30332

Volume-Number: Volume 7, Number 17

From news  Sun Oct  5 17:25:37 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re:  Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 5 Oct 86 22:25:25 GMT
Draft-9: 2.3.folding

Date: Fri, 3 Oct 86 23:56:26 edt
From: [e-mail] (Mark Horton)

>Finally, there are all those emulator writers.  They might find it easier;
>then again, they might not.  If I were going to do an emulator on top of
>MS-DOS, then (since I don't work for Microsoft) I would probably use the
>existing filesystem just as a base to build the POSIX filesystem, almost
>the way UNIX builds a named hierarchical filesystem space out of inodes.
>Going to case insensitivity wouldn't help me a bit, because of the other
>limitations Mark mentioned.  It might help Microsoft, because they could
>change the 8+3 convention at the same time.  But unless they were willing
>to do that, it wouldn't help them either.  VAX-VMS might be easier, but
>again there are other problems I would have to solve.  Case-insensitivity
>would help me some, but I'd still have a lot of work ahead of me.

I'm not concerned very much about the amount of work the emulator
writer has to do, but I am concerned about the quality of the
resulting emulation.  If I'm a user of an emulator which is written
on an otherwise-reasonable case insensitive filesystem (VMS comes
to mind) which emulates case sensitivity, then apparent POSIX filenames
will bear little resemblance to real native filenames.  Either there's
an external table somewhere not unlike the UNIX directory/inode # tables,
or else file names are somehow encoded into longer native filenames.
I'm living with the latter kind of system now (Sun's PC/NFS, which makes
UNIX filesystems look like DOS filesystems) and the contortions it has
to go through to fit ordinary UNIX file names into DOS filenames are
a serious inconvenience.  The former kind of system makes it impossible
to access native files from inside the POSIX environment, unless someone
is awfully clever.

On the other hand, if case insensitive is an option for the emulator,
then two possibilities occur: (1) the vendor of the native operating
system can otherwise upgrade their filesystem to allow a clean POSIX
implementation (maybe they will arrange that their native OS conforms
directly to POSIX; wouldn't you consider it strongly if the market
starts to demand POSIX compatibility?) and (2) True UNIX systems have
the option to evolve to case insensitive, should a study be done and
the world conclude that insensitive is better.

I agree that a study should be done; I have my own intuitive feelings
on the subject, and there is quite a collection of operating systems
out there that went to extra work to be case insensitive, they can't
all be wrong, can they?  But by all means, this would make a great
human factors study for somebody.

    Mark

Volume-Number: Volume 7, Number 18

From news  Sun Oct  5 17:26:38 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 5 Oct 86 22:26:23 GMT
Draft-9: 2.3.folding

Date: Sat, 4 Oct 86 04:19:12 CDT
From: dutoit![e-mail]
Subject:  Case sensitive file names

The suggestion that POSIX be required (worse, permitted) to conflate
cases in file names is utterly loony.  We have enough portability
problems already in reconciling System V with 4.x without trying to
make Unix compatible with MS-DOS.

It is granted that Stu Feldman committed a rare lapse of taste in
accepting both `makefile' and `Makefile' (thus dooming everyone to
typing `cat ?akefile') and that Fowler apparently compounded the
distinction to the point of felony by encouraging both kinds of
?akefiles to exist and have different meanings.

Nevertheless, neither the possibility of silliness in choosing file
name conventions nor the dubious advantages of permitting Unix to be
embedded in other systems are relevant; what is important is that such
a subtle yet central change would be certain to make transport of
programs and of files more onerous.  This is not a wise thing for an
endeavor devoted to promoting portability.

    Dennis Ritchie

Volume-Number: Volume 7, Number 19

From news  Sun Oct  5 17:32:11 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 5 Oct 86 22:31:52 GMT
Draft-9: 2.3.folding

Date: Sat, 4 Oct 86 16:54:37 PDT
From: hoptoad![e-mail] (John Gilmore)
Subject: Re: Case sensitive file names

> From: [e-mail] (Mark Horton)
> Another problem is that emulations on other operating systems,
> such as VMS or MS DOS, will become impossible without drastic
> changes to their file systems.

I think we should eliminate the hierarchical file system too (-:).
After all, VM/370 doesn't use it, nor does CP/M.  It would be too hard
to emulate.  (Thank Bog that MSDOS and the Mac added the feature, and
that Atari and Amiga started that way, or somebody might actually take
me seriously!)  We could consider getting rid of devices-as-files, though --
there's an idea that none of those people have picked up :-).

> After all, it's not like it was easiest to make the VMS filesystem
> case insensitive - that took extra effort on their part.

Their feeling it was worth the work for VMS doesn't make it right for Unix.

> I think it's a mistake to move in the direction of requiring other
> operating systems to become case sensitive.

Nobody is requiring anything of any other operating system.  We're
defining a *new* operating system here.

My impression was that the "new operating system" was supposed to look
very much like the set of features-in-common to the various Unix operating
systems.  If we are trying to standardize an environment that will
run under other operating systems, somebody better tell us quick.
I thought the "Portable Operating System" stuff was just a legalese hack
because we can't use the trademarked name "Unix".  Was I wrong?

>                                                        But I think
> it would be a mistake to require other systems to change if they
> are to support a POSIX emulation on top of them.  (On the other hand,
> it may be reasonable to expect other operating systems to support
> more general file name lengths and character sets, rather than things
> like the MS DOS 8+3 convention.  But in practice, this may be too
> painful to fix.)

Either they will implement POSIX compatability or they won't.  If we
define POSIX systems to be case insensitive, MSDOS would not qualify
anyway, since you can't use an arbitrary 14-character file name.  VMS
would have problems with files whose names contained [, ], or colon,
etc.  So they will have to provide some form of file name translation,
and they should handle the case issue at the same time they handle the
length and allowable character set issues.

Volume-Number: Volume 7, Number 20

From news  Sun Oct  5 17:33:06 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: so-called "case sensitive" file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 5 Oct 86 22:32:53 GMT
Draft-9: 2.3.folding

Date:     Sat, 4 Oct 86 23:09:29 EDT
From: Doug Gwyn (VLD/VMB) <[e-mail]>
Subject:  so-called "case sensitive" file names

It seems some people either have forgotten what UNIX is about
or never knew in the first place.  Pathname components are simply
strings of byte-chunked bit patterns.  It is not the operating
system's business to second-guess the user's intentions and
interpret the strings he has chosen to use for filenames in order
to "fix them" on his behalf.  (Some *applications* may elect to
impose restrictions on formats of filenames for files that they
deal with, when appropriate.)

I know several experienced UNIX users who rely on the freedom to
choose meaningful (*to them*) filenames, frequently using both
upper- and lower-case versions of a name concurrently for
different purposes (I do this myself).  If somebody can't cope
with names that are distinguished only by case, then of course
he is free to adopt his own naming procedures.  Automatic
enforcement of unnecessary restrictions by the kernel is not
desirable; that's the sort of thing UNIX was a rebellion against.

I also think this discussion was based on a misconception:
although we removed the note that some implementations may fold
cases in filenames, I can't find anything in the current draft
of the POSIX standard that prohibits this or other constraints
on filenames imposed by an implementation.  Presumably only a
layered implementation on a system that doesn't support
arbitrary characters in filenames would impose any such
restriction, but that's a marketing matter, not a technical one.

Volume-Number: Volume 7, Number 21

From news  Mon Oct  6 11:20:48 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re:  Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 16:20:30 GMT
Draft-9: 2.3.folding

From: axiom!drilex![e-mail]
Date: Mon, 6 Oct 86 10:24:22 edt
Subject: Re:  Case sensitive file names

I fully support Mark Horton's points about making case-insensitivity
optional in POSIX.  The fact remains that case-sensitivity in file names
is a Unix parochialism, and not a very good one, at that.  I've found that
case-sensitivity is not hard to teach, just hard to get along with.  I am
in a situation that is not unusual these days--I use several operating
systems each day (Unix, MS-DOS, VM/CMS, Burroughs MCP).  To remember the
peculiarities of each one is difficult--and case-sensitivity in file names
(and switches) is such a peculiarity.  The uppercase-lowercase system just
wasn't designed to convey that much information (in English)!  Look at
e. e. cummings!
---
Craig Jackson
UUCP: {harvard,linus}!axiom!drilex!dricej
BIX:  cjackson

Volume-Number: Volume 7, Number 22

From news  Mon Oct  6 11:22:44 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Case Sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 16:22:08 GMT
Draft-9: 2.3.folding

Date:     Mon, 6 Oct 86 0:30:45 EDT
From: Bernie Cosell <[e-mail]>
Subject:  Case Sensitive file names

To my view, the case folders have to make a VERY strong case that
case-sensitivity is a bad thing before we could justify BUILDING IN
that somewhat arbitrary limitation onto the operating system.  As has
been mentioned, if the filesystem is left alone, then it is easy to
envision that for certain uses, certain users *might* want to use (or
to use utilities that use...) a variant or (or layer on) stdio that
simply toupper's the filename string in the fopen call.  The users
that didn't need or want such a limitation should be free to do as
they wish.

Note that most of these other systems that are being presented as
exemplars have pretty horrible filename conventions (most punctuation
marks are not legal, certainly control chars aren't legal, the
equivalent of '..' is *built in* to the kernel, the operation of '.'
is *built in*.  I've always thought that was a crock!

>From what I've heard of the arguments so far, coupled with my biases,
I'd vote to keep it case-sensitive (but then, of course, I don't have
a vote so that hardly matters... :-).

  /Bernie

Volume-Number: Volume 7, Number 23

From news  Mon Oct  6 11:31:10 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: POSIX system range [more case sensitivity]
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 16:30:37 GMT
Draft-9: 2.3.folding

From: cybvax0!frog![e-mail]
Date: Mon, 6 Oct 86 08:56:55 edt
Subject: POSIX system range

In a comment on the sensitive issue of UPPERCASE us lowercase, John
Gilmore stated:

 "My impression was that the "new operating system" was supposed to look
  very much like the set of features-in-common to the various Unix operating
  systems.  If we are trying to standardize an environment that will
  run under other operating systems, somebody better tell us quick.
  I thought the "Portable Operating System" stuff was just a legalese hack
  because we can't use the trademarked name "Unix".  Was I wrong? "
     ( Volume-Number: Volume 7, Number 20)

The POSIX effort is defining an operating system interface, the boundary
layer between application and OS Services; not an "operating system".
One point is that we are not trying to specify the implementation.
We also want a portable environment that can work with various UN*X
versions. But, it should also work with some range of hosted systems,
and systems developed from scratch.  The name POSIX is to provide a
handle for such a thing without treading on the AT&T Trademark.  However,
The purpose is to define application portability beyond the scope of the
language constructs, but without necessarily specifiying a specific
implementation or specific version of system from a specific vendor.
If we reverse the implicit question "Why not UN*X" and ask "Why not hosted?"
it is useful.  If we vary from System V or Berkeley, we would like to know,
and have some rationale for that (or not vary); similarly if we define
constraints that prevent hosting we should have a rationale for that,
or not propose such constraints.

    For information, POSIX has been proposed as a FIPS standard,
which would have a substaintial impact on government purchases when
that becomes finalized, and the first US Government purchase spec for
a POSIX system went out in Oct.  So we are not concerned with minor
legalisms, but practical solutions in the real world.  If the definition
aids significantly in this, we have done well; if not, ...





Volume-Number: Volume 7, Number 24

From news  Mon Oct  6 12:07:57 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 17:07:33 GMT
Draft-9: 2.3.folding

Date: Mon, 6 Oct 86 09:56:50 edt
From: philabs!nyit![e-mail] (Rick Ace)

Regarding comments by Mark Crispin <[e-mail]>:

> I would like to add a loud "Bravo!" to Mark Horton's message!  The present
> case sensitivity of the Unix filesystem is a real drag, and something that
> has regularly and reliably caused me problems when working in a heterogenous
> environment.

What specifically is wrong with case-sensitivity?  I work on both
case-sensitive (UNIX) and other (TOPS-20) systems regularly, and
have no problems in switching between them.

>              As far as I can tell, the only individuals who actually *like*
> case sensitivity in Unix are the high-schoolish hackers who think it's really
> cute to write programs with separate -1, -l, -I, and -L switches.

And many software professionals.

> I think that the most reasonable proposal is to do a free case match on input,
> so that "more foobar" is the same as "More FooBar", etc.  On output, you first
> do a free case match to see if there is an extant file and if so preserve the
> case of that file.  In other words, if I overwrite FooBar but specify foobar
> or FOOBAR, the file is still called FooBar.  Otherwise, use whatever case the
> user specifies.  Renaming would always use the case the user specifies, so the
> user can rename foobar to FooBar, etc.

Changing the UNIX kernel to behave like this is, of course, within the
capabilities of a single programmer.  However, not all filename recognition
under UNIX occurs in the kernel, and you're going to have an
awesome task finding and rewriting all those user-mode programs that
know implicitly that filenames are case-sensitive.  The problem is
exacerbated by the fact that you're going to a more complex scheme
than what was there in the first place.

> ... a FooBar.Txt file is possible on TOPS-20, but only by
> F<^V>o<^V>oB<^V>a<^V>r.T<^V>x<^V>t.
> For once, I don't favor the TOPS-20 way of doing things.  TOPS-20's scheme is
> alright if you started with case independence to begin with, but I don't think
> it would fit in well into Unix, and certainly not without a major flag day.  I
> hope that my suggestion above could fit in with only minimal inconvenience.

It could fit in *part of the way* with minimal inconvenience.

> I found on TOPS-20 that no serious user used case-sensitive filenames.

You've got the cart before the horse.  No serious TOPS-20 users used
case-sensitive filenames because of the inconvenience in entering
filenames with embedded lowercase characters.  On output, filenames
with embedded ^V characters are aesthetically unpleasant as well.

> Everybody
> appreciated the case-insensitivity of the interface, even though it took the form
> of coercing to upper case.

You can replace the word "appreciated" with the words "became accustomed to".
Also, this argument fails on the grounds that it's hard to get people
to vote rationally on a subject that involves a decision to change
from something they're comfortable with.

>                         My experience also suggests that case sensitivity is
> a pain in the a**; I tried writing a major utility in Interlisp using mixed case
> function and variable names and eventually gave up when most of my errors turned
> out to be case errors.

How about keeping all variable names in one case?

>                     It's *so* much easier to keep the shift lock key down...
>
> -- Mark --

It's just as easy to leave the shift lock key up.  Many typists do.


The issue of case-sensitivity is a subjective one, thus you'll always
find many vehement proponents on both sides of the fence.  At this
point in the development of UNIX, such a fundamental change in the
behavior of the OS would receive at best only partial acceptance among
the myriad UNIX implementations, leading to even more divergence.
This effect diametrically opposes the purpose of a standard.

-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY  11568
[phone]

{decvax,seismo}!philabs!nyit!rick


Volume-Number: Volume 7, Number 25

From news  Mon Oct  6 17:40:19 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 22:40:02 GMT
Draft-9: 2.3.folding

From: seismo!hadron![e-mail] (Joseph S. D. Yao)
To: ut-sally![e-mail]
Date: Sun, 5 Oct 86 11:52:40 edt
Summary: Case sensitivity is useful; harms only those not used to it.
Organization: Hadron, Inc., Fairfax, VA

In <[e-mail]>, [e-mail] (Mark Horton) writes:
> Message-Id: <[e-mail]>
> Newsgroups: mod.std.unix
>
> I note that the committee recently decided that all file names
> in conforming systems must be case sensitive, for example,
> makefile and Makefile must be different files.  ...
> I think this is a mistake.  UNIX is the only major operating system
> that treats things like file names, logins, host names, and commands
> as case sensitive.  The net effect of this is that users get
> confused, since they have to get the capitalization right every time.

Since this is primarily an opinion, I'll say that I think any such
"confusion" is a product of someone getting wedded to odd ways of
doing things in a single-case environment, and not really learning
their own language.  Only the followers of the late great e. e.
cummings have any problem with "normal" use of different cases.
(Yes, German does it differently.  Fine!  AS LONG AS THERE IS A
STANDARD CONVENTION, I am willing to let Nouns be Uppercasen.)
I use both cases for reasons and, now that I have been weaned away
(for years!) from single-case environments, I find them very limiting.
After all, we DO have two cases here, and they are separate characters
that can be used separately.  Not to mention that UC-lc conversion
is only easy in the USASCII standard -- ISO and other conversions may
be quite difficult.

The sole time I like case independence is on the occasional text
search (often because some @#$% case-independent language allowed
a whimsical program to vary case without care).  Vi/ex's ":set ic"
mode works well for this, but I wish there were an "ignorecase"
flag to the grep family.  (-ic:ascii / -ic:deutsche / ... ?)
[ There is:  "grep -i"  -mod ]

(Anecdote: UPPER CASE ONLY is a product of the original TTYs' design.
A study had said that  l o w e r  case was easier to read!  but it
was decided to be UC-only, when a Board member asked the president
whether he wanted to be responsible when the name of God came over the
wires ... in lower case ...)

The emulation argument,
> Another problem is that emulations on other operating systems,
> such as VMS or MS DOS, will become impossible without drastic
> changes to their file systems.
almost swayed me, except that this is not an emulation document,
this is an OS document!
[ It's neither:  it's an interface document.  -mod ]
  And I remembered that it's quite possible
to provide a "flexnames"-type of mapping: RATFOR does something
similar.  Perhaps POSIX might wish to add a codicil, regarding
emulations ("hosted" implementations?), that gives some relaxation
and some requirements for minimum performance.  Perhaps they do
not want to relax their standards for emulations at all.  Their
privilege (considering that the Committee includes many vendors).
[ Hosted systems have been considered in excruciating detail
in writing the standard.  -mod ]

In article <[e-mail]>, MRC%PANDA@SUMEX-AIM (Mark Crispin) writes:
>case sensitivity of the Unix filesystem is a real drag, and something that
>has regularly and reliably caused me problems when working in a heterogenous
>environment.

See above.

There follow several comments on the use of mixed case.  OF COURSE
people won't use mixed case when the operating system stands in the
way of using it comfortably!  And if hackers aren't taught better
than to mix 1, I, L, O, and 0 in their codes (as a certain major
stinker of a company does -- using them EXCLUSIVELY -- in software
released with an alleged source-code license!), then people should
undertake to educate them ... and their alleged educators.

When I name a file FooBar, I better well come back and find it named
FooBar ... NOT FOOBAR or foobar or (God help us) FoObAr.

>            ...  It's *so* much easier to keep the shift lock key down...

I HATE it when people do this to my terminal ... and leave it
that way ...
--

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
            [e-mail] (not yet domainised)

Volume-Number: Volume 7, Number 26

From news  Mon Oct  6 17:55:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 22:55:36 GMT
Draft-9: 2.3.folding

The discussion has been interesting and has brought up some topics,
such as what case insensitivity means in non-English languages, that
many of the readers were evidently unaware of.  However, it's getting
a bit out of hand.

IEEE P1003.1 is interested in promoting portability of applications
by defining a UNIX-like operating system interface.  Any major change
from a feature of *every* variant of UN*X, such as case-sensitive
file names (really, filenames as uninterpreted byte strings), needs
major justification before being considered.  So further assertions
of the form "I want it because I like it" are not of interest.  It
would be most interesting to see the results of a survey on user
reaction to case sensitivity or insensitivity, but this newsgroup
isn't the place to conduct such a survey, and it's not clear that
the results would be relevant to 1003.1 anyway (what does case
mean in Japanese or Finnish)?

So, unless you've got something new to say on this subject, please
let's go on to something else.

Volume-Number: Volume 7, Number 27

From news  Mon Oct  6 18:00:50 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Administrativia
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 23:00:31 GMT
Draft-9: mod.std.unix

Thanks to John B. Chambers for guest moderating while I was swapped
out last week (to the USENIX Board meeting in Monterey).

It appears the newsgroup name change from mod.std.unix to comp.std.unix
is imminent.  Details as they become available.

Volume-Number: Volume 7, Number 28

From news  Mon Oct  6 18:07:41 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: POSIX book cost and P1003 participation
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 23:07:23 GMT
Draft-9: Trial.Use

[ This is a first for this newsgroup:  an anonymous posting.
The submittor asked to be signed "participant in 1003 effort."
-mod ]


IEEE is one of the lowest cost sources of standards; both CBEMA(X3)
[ who produce the X3J11 C Standard documents  -mod ]
and ISO tend to charge more for similar documents.  Part of this is
due to the fact that IEEE uses commercial distribution channels,
and thus can print higher volumes than if they were the only source.
For those of us who are putting in hundreds of hours of time (and our
companies who pay for that) substantial travel costs for meetings,
and even the per hour costs of sorting through mod.std.unix,
[ Amen -mod ] $20 is a drop in the bucket.

Now for a more challenging thought ... I'm not sure there is much use
in feedback from persons who cannot afford the $20!  Clearly they are
not professionally involved in this area or they would have a cause or
justification for the expense.  Any company in the computer industry
or related fields can afford $20 to find out what the federal government
is proposing be made a Federal Purchasing Specification, if not just
to keep employees current.  End user sites would have the same interest
in knowing what is "coming down", so they can respond intelligently
to the the multitude of products coming out.  I can see some limit
on the number of copies that a University might be willing to buy,
but each one has a book store, and if there are enough UNIX users on
campus that store can buy the book at a discount (or a user group could
put in a bulk order).  For a class of interested professionals, the
$20 is a minimal investment in keeping up with technology.  So I will
stand on my comment.

For those who consider this process to be of significant interest, they
can join the working group or corresponding group.  Working group members
attend meetings, and that is a moderate expense.  Correspondents are expected
to provide written feedback, and specific proposed wordings that would
improve the document.  These groups both get all of the mailings, drafts,
etc. (and the glory of having their names printed in the front of the book).
With the fairly tight budget constraints of the IEEE, if the correspondent
group gets too big we may need to charge them for the costs of distribution
of materials (far more than the $20) (so far that has not happened).

Finally, we hope to get the next draft on line in some form so persons
can "see" what is happening, and comment on current status information.
But I suspect that transfering that in bulk over UUCP, and printing it
locally is not a way to save $20 (phone, computer, paper, manpower
expenses will exceed $20 in most modern countries).

Volume-Number: Volume 7, Number 29

From news  Mon Oct  6 18:16:38 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: job control
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: POSIX Appendix C
Date: 6 Oct 86 23:15:47 GMT
Draft-9: job.control

From: pyramid!utzoo![e-mail]  (Henry Spencer)
Date: Sat, 4 Oct 86 03:03:30 PDT

After some activity back when the Unix standard was with /usr/group, I've
"gone dormant" on standardization work through lack of time.  I haven't
even seen most of the P1003 stuff.  However, I understand that there is
a proposal to incorporate Berklix-like "job control" into P1003.  Given
the interest in getting some new topics into mod.std.unix, I'm submitting
the following.  It's a slightly touched-up version of a paper Ian Darwin
and I submitted to the /usr/group standards effort, arguing strongly that
neither 4BSD "job control" nor SysV "shell layers" should be incorporated
into a standard.  Since I haven't seen the detailed P1003 proposal, it's
possible that some of this is out of date, but on the whole I think it's
of interest nonetheless.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

[ Perhaps whoever has the original online copy of the current P1003
proposal could submit it?  That would probably be worthwhile even if
it had to be broken into several articles for space reasons.  -mod ]









             Comments on Terminal I/O, Specifically `Job Control'


                                Henry Spencer

                            University of Toronto
                                 utzoo!henry


                                  Ian Darwin

                            University of Toronto
                                 utcsstat!ian







`Job Control', What It's Really About

     There is no longer any argument that it is desirable  to  permit  orderly
user  interaction  with multiple processes.  Unfortunately, a whole generation
of Unix users has had their view of this concept warped by the dreadful way it
was  implemented  by Berkeley.  And AT&T, in its recent attempt to address the
problem, has taken the easy way out instead of doing it right.

     The basic concept involved here is multiplexing,  not  `job  control'  or
process  suspension.   The ideal is something like the environment on the Bell
Labs Blit, where multiple processes run simultaneously  in  multiple  windows,
and  the user can switch his attention and his interaction from one to another
at will.  There is a popular misconception that doing this *requires*  a  Blit
or a similar highly-intelligent terminal; this is simply not true.

     Window-based multiplexed interaction is harder to do when the terminal is
dumb,  but  even  the Blit is not actually writing things into several windows
*simultaneously*:  it just looks that way because of the high-speed multiplex-
ing  involved.   There  is no intrinsic reason why this multiplexing cannot be
done at the other end of the communications line when the terminal is  incapa-
ble of doing it.

     The multiplexing can be done in the kernel (albeit at  considerable  cost
in  added kernel complexity) or in a user process (given suitable interprocess
communication).  In either case, the fundamental structure is quite simple:  a
central  `manager'  coordinates  terminal  i/o to and from `client' processes,
each of which has total control of its own "virtual terminal".  The  manager's
job  is  simulating  multiple  virtual terminals on a single real terminal, by
routing input to the appropriate process and placing output in the appropriate
area of the screen.





                                    - 2 -



     The basic characteristics of such a multiplexing  system  are  that  each
process  has  what  looks (to it) like a private terminal, and that all i/o to
and from the user is centrally supervised.  This  is  precisely  analogous  to
file i/o under Unix:  simultaneous independent activity by multiple processes,
coordinated by a central manager which multiplexes physical resources so as to
prevent interference.  The benefits are similar:  individual processes neither
know nor care about the multiplexing, and useful high-level  abstractions  can
be implemented in one central place.

Job Control and Layers:  Half-Baked Approaches

     The existing schemes, Berkeley `job control' and  AT&T  `layers',  unfor-
tunately  are  clumsy  and  incomplete  attempts  at  implementing multiplexed
interaction.  Neither one  makes  any  provision  for  simultaneous  on-screen
activities  by  more  than one process, except for the `cop-out' of permitting
multiple processes to intermix their output at random.  But there  are  deeper
problems.

     Both schemes require that *every* *program* which is going to participate
in  multiplexed  interaction  must contain code to allow for this possibility!
User programs must be prepared to redraw  the  screen  on  request,  with  the
requests  coming  from  the kernel in the Berkeley scheme and from the user in
the System V.2 scheme.  This is an abomination.

     Not only does this demand specialized code in every user program, but  it
entirely  denies  multiplexed  interaction  to the bulk of Unix programs.  The
concept of `redraw the screen' is meaningful  only  for  interactive  programs
with  full-screen  interfaces.   The result of, say, an *egrep*, once replaced
on-screen by (say) the editing buffer of a *vi*,  is  gone  for  good.   Since
*egrep*  is  not an interactive program, it is no longer around to be asked to
redraw its output.

     The heart of the problem is that neither job control  nor  layers  imple-
ments  the  crucial half of a window system:  centralized management of screen
updates.  It has long been accepted that multiple processes cannot  safely  do
updates  to disks without centralized management and consistency control.  The
same obviously applies to terminal i/o:  orderly simultaneous interaction with
multiple  processes  requires centralized supervision of the interaction.  The
existing schemes supervise input but not output.

     It is obvious *why* this deficiency exists:  supervising  output  is  the
hard part.  The idea of switching input from one program to another is reason-
ably straightforward.  Differences in input handling,  such  as  `cooked'  vs.
`raw'  modes,  are relatively minor problems, since the user can be conversing
with at most one process at a time.  But a CRT terminal  permits  output  from
multiple  processes  to  be  displayed simultaneously, and coordinating screen
updates isn't trivial.  Furthermore, there is no agreement on the precise user
interface  that  should  be presented for output -- consider, for example, the
religious debates over overlapping vs. non-overlapping  windows  --  and  this
discourages  attempts  to  provide  a single and relatively inflexible central
solution.  The immense variation in CRT-terminal control  sequences  puts  the
icing on the cake.






                                    - 3 -



     Nevertheless, these problems *can* be solved.  There are at least  three,
and  probably several more, complete window systems in experimental use.  Some
of them have performance problems, and most of them are outside the kernel and
hence have interprocess-communication problems, but they do work.

Standardizing Multiplexed Interaction:  A Recommendation

     As mentioned above, several experimental window  systems  already  exist.
(This is quite apart from the `real' window systems on bitmapped workstations,
which are also relevant.) Experience with these and other  implementations  of
the  same  concept will yield a wealth of knowledge on how best to handle this
function.  It is important that this experimentation, and the adoption of  the
results  that come out of it, not be stifled by further `official endorsement'
of incomplete and badly-designed existing schemes.

     The best approach for P1003 to take on this matter would  be  to  reserve
some  characters,  and some flag bits, for implementations of multiplexed user
interfaces, but not to specify any such  interface  at  this  time.   Such  an
attempt  to  specify the interface would be premature, especially when the two
approaches under consideration are  already  known  to  be  grossly-incomplete
botches.

     *Neither Berkeley `job control' nor AT&T `layers' is an  adequate  imple-
mentation  of  a  multiplexed user interface*.  *Neither one should be cast in
concrete as a standard at this time*.

A Retraction

     Our previous recommendation was that, if multiplexed  interaction  *must*
be  standardized,  AT&T `layers' would be a better place to start.  The layers
system, unlike Berkeley job control, does do input  multiplexing  more-or-less
correctly,  and  hence  is essentially upward-compatible with true window sys-
tems.  It has several desirable characteristics:  independent  tty  state  for
each  layer,  suspension/resumption  invisible  to  the  processes,  a central
manager process which is *not* imbedded in a shell, and an implementation that
does not have ramifications everywhere.

     Nevertheless, as discussed above, it doesn't do the  hard  part:   output
multiplexing.   It  also  has  some  annoying  implementation  limits,  which,
although they wouldn't necessarily have to propagate into  a  standard,  might
well  propagate  into  most  early implementations.  Its major problem is that
it's not clear how to extend  it  to  centralized  output  management  without
imbedding said management inside the kernel.

     We therefore retract our recommendation for  standardizing  layers  as  a
second choice.  The proper course is to standardize nothing, at least until we
understand the user-interface issues and the implementation problems better.

Specifics

     A decision not to standardize a multiplexed-interaction  scheme  notwith-
standing,  there  are a few useful minor things that can be standardized.  The
*termio* structure probably should have a reserved character or two  (or  room
for  same)  and  a few reserved bits (or room for same) to permit kernel-based




                                    - 4 -



implementations of multiplexing.

     In particular, almost any multiplexing scheme using ordinary ASCII termi-
nals  will need a special character to attract the attention of the multiplex-
ing software.  Without this, it's very difficult  to  do  things  like  moving
between windows.  Reserving space for such a character might be useful; recom-
mending a default choice for the character would be very valuable, as it would
forestall unnecessary differences between implementations.  Control-Z would be
plausible.

     Implementing supervision of multiplexed interaction in user processes  is
difficult  in  many  existing Unix implementations, minimal implementations of
the existing P1003 standard among them.  The basic problem is that normal user
processes  are  definitely aware that their output is going to a terminal, the
device-independence of Unix  i/o  notwithstanding.   Screen-oriented  programs
doing *ioctl*s are the biggest problem.  A less obvious glitch is that *stdio*
adjusts its buffering strategy depending on whether output is to a terminal or
not;  this  is  a major nuisance with some existing window systems.  Something
like the `pseudo-tty' concept would be very useful:   an  entity  which  looks
like  a  terminal from one side, but whose behavior is under user-process con-
trol from the other side.  Some existing systems do implement such things, but
the lack of standardization largely prevents use of them in portable programs.

Suspending Processes:  A Non-Issue

     Several people have objected to AT&T layers, and similar  approaches,  on
the grounds that `...but 4BSD lets me suspend misbehaving processes...'.  This
is silly; a process-suspension  facility  can  be  very  simple  if  it  isn't
required to double as a multiplexing system.

     If it is thought desirable to standardize process  suspension,  we  would
suggest the following.  Some magic character (control-Y?), when typed as input
to a tty/window, suspends all processes  attached  to  that  tty/window.   The
suspension can be, and should be, utterly invisible to the processes involved.
This avoids the sticky problem of how to notify the  processes  without  doing
incompatible things to the *signal* mechanism.  The suspension probably should
have a permission requirement analogous to that of signals:  if the  effective
userids  of  the user and the process don't match, the suspension doesn't hap-
pen.  This is necessary to prevent major  security  breaches  like  suspending
*passwd*(1) in the middle of an update to the password file.

     Note that this suspension facility isn't very useful in  the  absence  of
multiplexed  interaction  --  you  can't  *do* anything to a suspended process
without access to another (real or virtual) terminal -- but the  two  concepts
are nevertheless quite independent.  There is no need to confuse them.













Volume-Number: Volume 7, Number 30

From news  Mon Oct  6 18:24:32 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: drafts since POSIX Trial Use Standard
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 23:24:09 GMT
Draft-9: mailings

From: ihnp4!pegasus![e-mail] (Tony Hansen)
Date: Wed, 1 Oct 86 18:31:52 CDT

I received the hard-cover copy of the trial use standard as a member of the
corresponding group. However I haven't seen anything since then. Has there
been any correspondence since the hard-cover book which I should have
received? I have seen a few references in mod.std.unix regarding some
additional appendices/modifications since the hard-cover, but no indication
about who should have received a copy of them.

[ Decisions have been made in working group meetings about changes in
the document, but there has been no complete draft produced or distributed
to anyone since the printed book became available.  There have been several
mailings of administrativia, RFCs, proposals, and such to the interest list.
There was a cleanup of that list recently involving every person on it being
sent a note asking for confirmation of address and continued interest.
It is possible that you didn't get one or that it didn't get sent back.
If so, inquire at the address to be found in the next article.  -mod ]

If other people might be interested in the answer to this question, you
might post your response as well as mailing it to me. Thanks.

[ Don't post it:  there's no point in repeatedly asking the same question.
-mod]

                    Tony Hansen
                    ihnp4!pegasus!hansen

Volume-Number: Volume 7, Number 31

From news  Mon Oct  6 18:30:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 23:30:08 GMT
Draft-9: Access.Standards


This is the latest in a series of similar mod.std.unix articles.


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on networking, graphics, database,
    internationalization, performance measurements, realtime, and security
X3J11 (C language)
/usr/group Standard
System V Interface Definition
X/OPEN PORTABILITY GUIDE


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They have recently produced the 1003.1 "POSIX" Trial Use Standard.
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.  Or contact:

    IEEE Service Center
    445 Hoes Ln.
    Piscataway, NJ 08854

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

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

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
    Charles River Data Systems
    983 Concord St.
    Framingham, MA 01701
    decvax!frog!jim

Sufficiently interested parties may join the working group.
The next scheduled meetings of the working group of the committee are

    9-11 December 1986    Atlantic City NJ with X3J11
    2-6 March 1987        Toronto, ON
        June 1987        Phoenix, AZ    the week of USENIX
        September 1987    New Orleans, LA

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (Amdahl), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Both will meet concurrently with 1003.1 in Palo Alto in September
(though 1003.2 will meet concurrently only on the morning of the 17th),
and inquiries should go to the same address as for 1003.1.

There are two Institutional Representatives to P1003:  John Quarterman
from USENIX and Heinz Lycklama from /usr/group.  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 (currently known as mod.std.unix,
eventually as comp.std.unix).  An article related to this one just
appeared in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.

The May/June 1986 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in February 1986 on the areas of Networking,
Internationalization, Graphics, Realtime, Database, Performance, and
the proposed new group on Security.  Here is contact information for
those working groups as taken from that article (if you are interested
in starting another working group, contact Heinz Lycklama at the address
below):

/usr/group Working Group on Networking:
    Dave Buck
    D.L. Buck & Associates, Inc.
    6920 Santa Teresa Bldg, #108
    San Jose, CA 95119
    [phone]

/usr/group Working Group on Internationalization:
    Brian Boyle            Karen Barnes
    Novon Research Group        Hewlett-Packard Co.
    537 Panorama Dr.        19447 Pruneridge Ave.
    San Francisco, CA 94131        M/S 47U2
    [phone]            Cupertino, CA 95014
                    [phone], ext 2438

/usr/group Working Group on Graphics:
    Heinz Lycklama
    Interactive Systems Corp.
    2401 Colorado Ave., 3rd Fl.
    Santa Monica, CA 90404
    [phone]

/usr/group Working Group on Realtime:
    Bill Corwin            Ben Patel
    Intel Corp.            EDS Corp.
    5200 Elam Young Pkwy        P.O. Box 5121
    Hillsboro, OR 97123        23077 Greenfield
    [phone]            Southfield, MI 48075
                    [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 Celluri            Dave Hinant
    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
    Computer Systems Div.
    Gould Inc.
    1101 East University
    Urbana, IL 61801
    [phone]


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

There is frequent discussion of X3J11 in the USENET newsgroup mod.std.c,
which see.  (That newsgroup will eventually be known as comp.std.c.)


The /usr/group Standard is the principle ancestor of P1003.1:

    /usr/group Standards Committee
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95050

The price is still $15.00.


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

    System V Interface Definition, Issue 2
    Select Codes 320-011 (Volume 1) and 320-012 (Volume 2)
    or Select Code 307-127 (both volumes).
    AT&T Customer Information Center
    2833 North Franklin Road
    Indianapolis, IN 46219
    1-800-432-6600, operator 77.

The price is about 37 U.S. dollars for each volume or $52 for the pair.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order.  Previous SVID owners should
have received a discount coupon to upgrade to Release 2 for only $37.

Volume 1 is essentially equivalent to the whole previous SVID;
Volume 2 is mostly commands and a few add-ons (e.g. curses).
A third volume is expected in the last quarter of 1986 to cover new
items in System V Release 3, such as streams and networking.  There may
be an upgrade discount similar to the previous one.  A draft copy is
reputed to be available now to source licensees.


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

X/OPEN is "A Group of European Computer Manufacturers" who have produced
a document intended to promote the writing of portable facilities.
(They now have member computer manufacturers from outside Europe.)
Their flyer remarks (in five languages), "Now we all speak the same
language in Europe."

The book is published by

    Elsevier Science Publishers
    Book Order Department
    PO Box 211
    1000 AE Amsterdam
    The Netherlands

or, for those in the U.S.A. or Canada:

    Elsevier Science Publishers Co Inc.
    PO Box 1663
    Grand Central Station
    New York, NY 10163

The price is Dfl 275,00 or USD 75.00.  According to the order form,
"This price includes the costs of one update which will be mailed
automatically upon publication."  They take a large number of credit
cards and other forms of payment.


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a Registered Trademark of AT&T."
And POSIX is a trademark of IEEE.

Volume-Number: Volume 7, Number 32

From news  Mon Oct  6 18:38:15 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Oct 86 23:37:03 GMT
Draft-9: Access.User.Groups


This is the latest in a series of similar mod.std.unix articles.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG
newsletters:    ;login:, CommUNIXations, EUUG, AUUGN
magazines:    UNIX REVIEW, UNIX/WORLD


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

    USENIX Association
    P.O. Box 7
    El Cerrito, CA 94530
    415-528-8649
    {ucbvax,decvax}!usenix!office

USENIX sponsors two USENIX Conferences a year, featuring technical papers.
The next one is in Washington, D.C., 20-23 January 1987.
They publish ";login:  The USENIX Association Newsletter"
which is sent free of charge to all their members.


/usr/group is "the commercially oriented UNIX system users organization."

    /usr/group
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95054
    408-986-8840

They publish a newsletter called CommUNIXations.

The annual Uniforum Conferences are sponsored by /usr/group
and feature a large trade show.  The next one is in D.C.
at the same time as the next USENIX Conference.  USENIX
and /usr/group have held several concurrent conferences
in the past and will probably do so in the future.


Both USENIX and /usr/group also have tutorials at their
conferences and both sponsor other meeting activities
in addition to their regular conferences.


EUUG is the European UNIX systems Users Group.

    EUUG secretariat
    Owles Hall
    Buntingford
    Herts SG9 9PL
    England
    seismo!mcvax!euug

They have a newsletter and hold two conferences a year.


AUUG is the Australian UNIX systems users Group.

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

    seismo!munnari!auug
    [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each:
the next one will probably be in late February 1986.
They publish a newsletter (AUUGN) at a frequency defined
to be every 2 months.


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


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a Registered Trademark of AT&T."

Volume-Number: Volume 7, Number 33

From news  Tue Oct  7 11:09:23 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 7 Oct 86 16:08:16 GMT
Draft-9: Access.Standards

[ Some updates on 1003 meetings from chairs of 1003.1 and 1003.2.
For those of you who don't like digests:  this is not a digest,
it is a compendium.  -mod ]

From: harvard!cybvax0!frog!jim (Jim Isaak, P1003.1 Chair)
Date: Tue, 7 Oct 86 09:25:06 edt

An update on meeting dates & locations

December  8-12    Atlantic City, NJ    Bally's Hotel & Casino
    (Same time/location as X3J11 C Standards Committee meeting)
    Host: Concurrent Computer Corporation (previously Perkin Elmer)

April    22-24    Toronto            Host: IBM (!)
        (Canadian UNIX Conference)

June    9-12    Phoenix (USENIX Conference)    No Host yet

Aug/Sept 31-4   East Coast Probably Washington DC area    No Host yet
 OR Sept 14-18    Boston (Same Time/loc as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)

From: pyramid!amdahl![e-mail] (Hal Jespersen, P1003.2 Chair)
Date: Tue, 7 Oct 86 07:25:57 PDT

[ This is an extract from a mail message.  There may be an article later. -mod ]

The 1003.2 (shell/tools) meeting is 8 December and may ooze over into the
small group meetings the morning of 12/9.

Volume-Number: Volume 7, Number 34

From news  Tue Oct  7 16:36:47 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Vowel-insensitive UNIX Filenames
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Oct 86 21:36:07 GMT
Draft-9: 2.3.folding

From: [e-mail] (Rich A. Hammond)
Date: Tue, 7 Oct 86 08:13:22 edt

As long as we're proposing case-insensitive filenames, we should
fix the real user interface problem and have vowel-insensitive
filenames.  We've had many problems with users who typed
"move" to rename a file, or once they had learned mv, couldn't
understand why "ct" didn't cat.  And of course, they are forever
trying to chdir to /user.  Clearly, vowel-insensitive filenames
i.e. move == mv, usr == user, ld == load, name == nm, ...
would eliminate many of the complaints about UNIX's user interface.

Rich Hammond    Bell Communications Research    [e-mail]

[ Ok, this is different, but I seem to recall the issue of command
names being beat to death in other fora, perhaps including a CACM paper.
If someone can recall the details, please post.

Also, I assume this wasn't really meant as input to P1003 (actually
P1003.2, since it's a shell interface issue), because that group is
trying to standardize what's there, not invent new things.

For that matter, it couldn't have been a *gasp* joke, could it?
-mod ]

Volume-Number: Volume 7, Number 35

From news  Wed Oct  8 19:02:28 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 00:02:14 GMT
Draft-9: 2.3.folding

From: caip!uw-beaver!geops!uw-atm![e-mail] (James M Synge)
Date: Wed, 8 Oct 86 09:17:04 pdt

Just a note on usefulness:  I've used two machines (Xerox XDE and Amiga) where
the case of a filename is preserved, but not used for comparisons.  This means
I can create a file called READ_ME, and be sure that it stands out (to some
extent) in a directory listing where most filenames are lower case or mixed
case.  This feature is a nice convenience.  Not essential, but nice.

I find it irritating to find filenames like makefile and Makefile in the
same directory, because I must then try to remember the searching scheme used
by make.  There are similar problems with mail and Mail.

None of this is to say it SHOULD be done one way or the other.  I simply want
it kept in mind that people must use these systems, and they have preferences
based on such things as levels of irritability and ease of use; not because
something is "right".
---
---------------------------------------------------------------------------
James M Synge, Department of Atmospheric Sciences, University of Washington
VOX: 1 206 543 0308 (Work)   1 206 455 2025 (Home)
UUCP: uw-beaver!geops!uw-atm!james
ARPA: geops!uw-atm![e-mail]

Volume-Number: Volume 7, Number 36

From news  Wed Oct  8 19:08:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 00:07:05 GMT
Draft-9: 2.3.folding

From: seismo!nbs-amrf![e-mail] (Don Libes)
Date: Wed, 8 Oct 86 19:54:05 EDT

I write programs for both case-sensitive (CS) and case-insensitive
(CI) systems.  As an applications programmer, I prefer case-sensitivity.

Why?  Because my code on the CI system is full of calls to upper(),
lower(), isupper() and islower(), while the CS programs don't have
any of that.  On the CS system, case is important - it would be a
mistake to map it either way.

On the other hand, take the CI system.  If I have a user-supplied
filename, depending upon the system I may have to case-map it before
calling open.  But suppose I'm reading a directory and I want to
match the filename against the entries.  Now, I definitely have to
case-map it before doing a string comparison.  Unless you want to
supply me with a filecmp() which is just a case-map wrapped around
a strcmp().  Seems silly.

Now you may think, I'm getting annoyed over one little case-map,
but as MRC points out, OSs tend to go about this in a big way.  For
example, VMS has case-insensitive filenames, logical names, device
names, usernames, symbols, etc.  Everytime I deal with an object,
the first thing I have to do is start worrying about case.
Depending upon the utility, library, language, etc I'm working with
I then have to start thinking if their interfaces are
case-sensitive or not.  I find all of this quite annoying.

That is why, as an application programmer, I much prefer case-sensitivity.

Please don't tell me I am insensitive to users.  I am not about to
argue here whether or not users have the intelligence to hold down
the shift key at the appropriate times.

As far as m/Mail, m/Makefile goes, the problem is not that users
find them easily confused.  That should've been obvious to the
genius who reused the name.  If you want, I can easily choose
filenames that you will find confusing, even in the same case.

As far as emulator's go, I daily use Eunice, which faces this very
problem of handling case-sensitive file names in a case-insensitive
environment.  As far as case-mapping, their solution is very
elegant.  (No other claims about the elegance of Eunice are
proffered here.)  I.e.  UNIX programs see a case-sensitive
filesystem.  Further, they are also allowed arbitrary characters in
a filename, outside the legal VMS character set.)

Don Libes   {seismo,umcp-cs}!nbs-amrf!libes

Volume-Number: Volume 7, Number 37

From news  Wed Oct  8 19:27:03 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 00:26:29 GMT
Draft-9: 2.3.folding

From: seismo!mnetor!spectrix!clewis (Chris Lewis)
Date: Wed Oct  8 11:00:33 1986
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada

Mod,

I'll leave this to your judgement whether to post this or not...
[ Judgement?  Who, me?  -mod ]

I'd rather everybody be very careful about making global statements like
"all other systems are case insensitive".  Many of the examples given
so far, eg: CP/M, VM/CMS *are* case sensitive.   When dealing with these
O/S's right down at the "system call level" (if you could call it that),
they *do* respect case.  The upper-casing is done in the command
interpreters (CCP, EXEC1, EXEC2, optionally in REX), and in the utilities.
[Most of the time it's damn difficult to get lower case into a VM/CMS
system in any way].  [That comment was not by the moderator -mod]
However, down deep (eg: CP/M BDOS, VM/CMS FSOPEN/FSREAD)
these systems will create files with mixed case and respect case in file
name searches.  One of my CP/M floppies still has a lower case named
file on it because Microsoft basic isn't smart enough to upper case
file names, and I haven't gotten around to writing the assembler code
to delete it.  One of the favorite CCP hacks is to zap the upper-case
command line code.

Yes, there are some systems that are truly case insensitive - Honeywell
GCOS comes to mind - it keeps its file names in BCD!

Further, I wonder whether any sort of conformance would help - every
system differs so much from each other, that case [in]sensitivity is
a very minor part.  Eg: 18 character 3 blank separated part file names
in CMS (gack ptui!) etc., etc., etc....  When writing an emulator you'll
almost always have to write your own filesystem handler anyways, with
specific escapes for "native mode" files.

Mind you, it would be nice to have file transfer utilities (eg: tar)
warn you that the file names you are putting on your tape may not be
unique/representable on a non-UNIX target.  Eg: warn when two files
on the tape differ only in case and when two files have the same name
within the first 8 chars.

Chris Lewis
UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis
Phone: [phone]

Volume-Number: Volume 7, Number 38

From news  Wed Oct  8 19:29:30 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 00:28:55 GMT
Draft-9: 2.3.folding

From: seismo!hpscda!hpdsd!hpda!hpisoa1!davel (Dave Lennert)
Date: Mon, 6 Oct 86 15:24:20 pdt

Perhaps a good approach might be to require POSIX applications to specify
filenames to the system as all lowercase in order to be truly portable.
As long as the filenames don't contain *mixed* case then case shifting to
all lower or all uppper (or leaving case insensitive) on the part of the
system won't result in name collisions.

A variant on this is to require all hardcoded filenames in applications
to be lowercase, but filenames supplied by a user could be passed to the
system unshifted by the application.  The user should know the case
limitations of the underlying system.

However, my preference is to have the POSIX interface support cases
sensitive filenames.  I agree with others that this will not be hard
to implement given some of the other things that will have to be
provided.

Volume-Number: Volume 7, Number 39

From news  Thu Oct  9 11:25:43 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Keywords: POSIX Appendix C
Date: 9 Oct 86 16:25:20 GMT
Draft-9: job.control

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Thu, 9 Oct 86 01:30:59 edt
Organization: AT&T Bell Laboratories, Columbus

I've made significant use of four different sorts of systems
for multiplexing, so hopefully I can provide some feedback on
their relative merits, from a user's point of view.

(1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
acts like a terminal.  This is unquestionably the best, but it
requires special hardware, and is an area that needs to be
standardized.

(2) A dumb-terminal window manager as Henry describes.  I've written
such a window manager; on a system that has ptys, select, and a smart
curses package, it's easy (my code is only 700 lines.)  It runs on both
4.2BSD and System V, provided that all three ingredients are present.
This package runs about as well as you could hope for, (the buffering
and ioctl problems Henry mentions are solved using ptys, and it doesn't
eat up much CPU time, and all my windows are the full 80 cols wide)
and I have a 60 line terminal so there's really room for two or three
windows.  I use this rarely, because I dont' like the "mushy" feeling I
get from the screen management layer.

(3) Berkeley job control.  Henry may think this is ugly, but from a user's
point of view, if you can't have a real bitmapped display, this is the
next best thing.  I strongly prefer it to (2).

(4) System V shell layers.  I don't use this very often, it's just not
very powerful and awfully inconvenient.  It can't pop you out from any
program that runs in raw mode, such as cu or rlogin, because there's
no way for a program to suspend itself.  rlogin really NEEDS to suspend
output in a non-window environment, otherwise your screen will be a mess.

I should mention that my major use of multiplexing is to switch between
rlogins to various other systems on our LAN, and a few local applications
such as vi, mail, and news.  For situations where I really need two windows
(e.g. developing a network client and server) I strongly prefer to do it
on a true window system.  It is possible that others, running other mixes
of applications, will feel differently.

My recommendation is, however, similar to Henry's, for the standard.
I don't think the dumb terminal window manager is the answer, but I
think it's clear we don't have the best answer yet, in general.  I do
think that certain things should be standardized:

(a) termio, or at least the subset that's commonly used.  You could always
    put in a few high level subroutines like the cbreak/nocbreak echo/noecho
    erasechar/killchar/baudrate routines in curses, just to provide a
    portable interface.
(b) an ioctl to find out the current window size, in chars and pixels.
(c) a pty-like mechanism.  (Streams may be a viable candidate here, or
    Illinois/Berkeley ptys might be expedient.)
(d) a software-multiplexing mechanism, like select.

    Mark

Volume-Number: Volume 7, Number 40

From news  Thu Oct  9 11:33:34 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: the scope of POSIX
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 16:33:13 GMT
Draft-9: 1.0 2.3.folding

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Thu, 9 Oct 86 01:46:35 edt

The spirited debate about case sensitive file names raises
an important issue: what is the scope of POSIX?  I think the
answer to the case issue may depend on the answer to the
scope issue.  It's pretty clear that whether names are case
sensitive is a religious issue, with many people on each side.
While I hope somebody does a human factors study, I won't get
into the technical merits of the different sides here.

I used to think that P1003 was just to be a standard that all
the UNIX systems would conform to, e.g. a way to smash System
V and 4.2BSD and Xenix into enough similarity so that it would
be possible to write a program that will run on all of them.
If this is the real intent of POSIX, that it's really to be the
standard for UNIX, and the name is just a trademark game, then
it's pretty clear we want to keep filenames as they currently
are: case sensitive.

But I'm not sure POSIX has such a narrow scope.  I hear mention
of hosted implementations, but no cries of "foul" about the
case-sensitive ruling from the vendors of those hosted implementations,
so either they don't consider it a problem, or I'm missing something.

I personally think POSIX could easily have a MUCH wider scope.
Let's look into the crystal ball.  In a couple of years, IEEE
or FIPS or ANSI or ISO or somebody publishes a final "Standard
for Portable Operating System Interfaces."  Now, say I'm a vendor
of some other operating system (say MS DOS, or VMS, or OS9, or QNX,
or AOS, or VM/CMS, or pick your favorite proprietary operating system.)
I see this standard, and think "If we enhanced our OS to support all
this POSIX stuff, we'd be able to market our OS as POSIX compatible,
and there's be a big software base we'd automatically support, and
we'd be eligible for all those government contracts."  I'd sure think
seriously about making the necessary enhancements to my standard system
(not an emulation built on top) to make it comply.

Now, for the most part, adding UNIX/POSIX functionality would amount
to adding some enhancements to the system.  (There will probably be
some major surgery in areas like the filesystem, but we're still talking
about an enhanced result.)  However, if I were such a vendor, I'd be
pretty reluctant to take my case insensitive filesystem and make it
case sensitive.  (But I'm not such a vendor; it would be interesting
to hear what the real vendors have to say.)  After all, maybe nobody
uses UNIX with their caps lock key on, or on an upper case terminal,
but MY system has lots of users like that, and I don't want to break
the ability for the caps lock users to communicate with the lower case
users.

I think it would be appropriate to ask what the scope of POSIX should
be.  Maybe some vendors should be queried about whether they might be
interested in someday conforming their systems to POSIX, and how they
feel about the case properties of their system.  They're the ones who
are really affected by all this.  Me, I'm used to doing everything in
lower case, as are most of you reading this.

    Mark

Volume-Number: Volume 7, Number 41

From news  Thu Oct  9 11:39:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Administrativia
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 16:39:16 GMT
Draft-9: mod.std.unix

>From: [e-mail] (Moderator, John Quarterman)
>Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
>Date: 6 Oct 86 23:00:31 GMT

>It appears the newsgroup name change from mod.std.unix to comp.std.unix
>is imminent.  Details as they become available.

>Volume-Number: Volume 7, Number 28

I've been informed that mod.std.unix will not change names at least until
the end of 1986.

Volume-Number: Volume 7, Number 42

From news  Thu Oct  9 11:46:41 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 16:46:20 GMT
Draft-9: Access.Standards

[ This will get incorporated into the next posting of the article
Access to UNIX-Related Standards.  -mod ]

From: pyramid!amdahl![e-mail] (Hal Jespersen, co-chair, P1003.2)
Date: Wed, 8 Oct 86 14:27:41 PDT

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

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.

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.

Meetings are normally held in conjunction with the 1003.1 group and
have a large membership overlap.  The next meeting is 12/8/86, and
possibly the morning of the 9th, in Atlantic City.  Future meetings
will generally be held on the day or two preceding 1003.1.

The 1003.2 mailing list is the same as 1003.1's.  Contact Jim Isaak to
be put on the mailing list.

[ That address is:

    James Isaak
    Chairperson, IEEE/CS P1003
    Charles River Data Systems
    983 Concord St.
    Framingham, MA 01701
    decvax!frog!jim

-mod ]

                Hal Jespersen
                [phone]
                ...{ihnp4|hplabs|seismo|decwrl}!amdahl!hlj
                Amdahl Corporation
                Mailstop 316
                1250 East Arques Avenue
                Sunnyvale, CA 94088-3470

Volume-Number: Volume 7, Number 43

From news  Thu Oct  9 16:53:25 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Oct 86 21:53:08 GMT
Draft-9: 2.3.folding

From: seismo!philabs!phri!cooper!cooper!chris (Chris Lent)
Date: Tue, 7 Oct 86 19:26:42 edt

Just wondering,
    Why not set up a few functions to determine how the heck
each operating system handles filenames?

    For case sensitivity how about something like:
        isfsense()
    which could be a macro to a constant or a function.

    Or better how about:
        isflegal(fname)
        char *fname;
    which would tell you if the operating system approves of your file
    name? Of course this could be done through existing functions
by opening the file, but this way COULD be implemented to reduce
file access overhead.

    But I think a good solution would be to follow FORTRAN-77's
example with the inquire statement which can get back the fully expanded
filename of an already open unit-number (file descriptor) or a
closed file.  I've found all F-77's I've tried to give back the
full pathnames on files.

    But I think that a minimum allowable character set for
filenames might be sufficient.  That is 'A-Z0-9.' would be fine
for most users I've run into.

Well that's about it
Chris Lent
ihnp4!philabs!phri!cooper!chris

Volume-Number: Volume 7, Number 44

From news  Fri Oct 10 15:09:43 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Keywords: POSIX Appendix C
Date: 10 Oct 86 20:09:06 GMT
Draft-9: job.control

From: nike!oliveb!felix!peregrine![e-mail] (Mike Wexler)
Date: Thu, 9 Oct 86 10:21:55 PDT
Organization: Peregrine Systems, Inc, Irvine Ca

>From: pyramid!utzoo![e-mail]  (Henry Spencer)
>Date: Sat, 4 Oct 86 03:03:30 PDT
>
>     Implementing supervision of multiplexed interaction in user processes  is
>difficult  in  many  existing Unix implementations, minimal implementations of
>the existing P1003 standard among them.  The basic problem is that normal user
>processes  are  definitely aware that their output is going to a terminal, the
>device-independence of Unix  i/o  notwithstanding.   Screen-oriented  programs
>doing *ioctl*s are the biggest problem.  A less obvious glitch is that *stdio*
>adjusts its buffering strategy depending on whether output is to a terminal or
>not;  this  is  a major nuisance with some existing window systems.  Something
>like the `pseudo-tty' concept would be very useful:   an  entity  which  looks
>like  a  terminal from one side, but whose behavior is under user-process con-
>trol from the other side.  Some existing systems do implement such things, but
>the lack of standardization largely prevents use of them in portable programs.

One idea would be to put Ritchie's streams in the standard or an extension
of the standard so that there is a "clean" way of writing user level window
managers.  Given this there would probably be many window managers implemented
and likes shells you wouldn't need a single standard one, but could provide
several and allow users to write their own.

[ Does anyone from the /usr/group networks or windowing systems groups
have any comments on this?  -mod ]

Volume-Number: Volume 7, Number 45

From news  Fri Oct 10 15:18:20 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Keywords: POSIX Appendix C
Summary: consider the virtual console paradigm as well
Date: 10 Oct 86 20:18:00 GMT
Draft-9: job.control

From: [e-mail] (Larry Campbell)
Date: Fri, 10 Oct 86 00:52:48 EDT
Organization: The Boston Software Works, Inc.

There's another flavor of terminal I/O multiplexing that Mark Horton
didn't mention.  It's widely available today; it requires no changes
to user mode code (in fact, its presence is not detectable by user
mode code); it does not require bit mapped or graphics terminals; and
I've found it to be more useful and pleasant than I would have guessed.

"It" is the "virtual console" feature found in most PC-based UNIX
implementations.  This does rely on memory-mapped video, but character-
mapped terminals work as well as bit-mapped ones.  Typically, four to
ten function keys are used to select four to ten virtual consoles.
Each virtual console occupies the entire physical screen;  you can
only see one at a time.  Keyboard input goes to the current (visible)
virtual console.  Since the video is memory mapped, switching is
instantaneous.

A process trying to write to a non-current virtual console will (fill
up some clists and then) block.  A process trying to read the keyboard
will block until the user switches to its console and types something.

This is all completely invisible to user programs;  they think they're
dealing with a perfectly ordinary 24x80 terminal.  No SIGTSTP, no window
size ioctls, etc.

I've used several "true" windowing systems before (Xerox Star, Apple
Macintosh, Microsoft Windows, Symbolics 3600) and I find I like the
virtual console paradigm far more than I would have anticipated.  It's
simple and uncluttered.

I'm not suggesting that virtual consoles become part of the standard;
just pointing out a useful alternative design.
--
Larry Campbell            MCI: LCAMPBELL   The Boston Software Works, Inc.
ARPA: [e-mail]   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     [phone]

Volume-Number: Volume 7, Number 46

From news  Fri Oct 10 15:22:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: IEEE standards
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 10 Oct 86 20:22:06 GMT
Draft-9: IEEE.standards

From: pyramid!nsc!hplabs!hpfcdc!donn
Cc: frog![e-mail]
Date: Fri, 10 Oct 86 08:52:40 pdt

For posting:

The most recent copy of the IEEE Newspaper "The Institute" has several
articles on the IEEE standards process.  (Not particularly related to
P1003.)  This is effectively "must" reading, as it explains several things
that need to be understood by the standards-makers (us), and also points
to some further required reading.

"The Institute" is distributed to (US domestic??) IEEE members.

Donn

Volume-Number: Volume 7, Number 47

From news  Sat Oct 11 01:24:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: multiplexing vs windows
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 11 Oct 86 06:23:59 GMT
Draft-9: windows

From: pyramid!utzoo!henry
Date: Fri, 10 Oct 86 20:38:59 CDT

The following was sent to me in private mail, with permission to publish.
He's got an interesting point.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry
-----
>From: ihnp4!mecc!sewilco
Subject: Re: Window-based multiplexing

My opinion is that the multiplexing characteristic of a line should be
separated from the windowing.  The multiplexing should also not be
terminal-oriented so it can be used as a multiplexed intersystem line.

I've heard several people echo my wish to be able to have file transfer
multiplexed with a terminal session, or have high-priority transfers
be interleaved with a long low-priority transfer.  And with computer
ports always in short supply it would be nice to use a $600 multiplexer
to add a few more terminals and printers (several WY-50 on a table is a
poor man's windowing system).

Scot E. Wilcoxon    Minn Ed Comp Corp  {quest,dicome,meccts}!mecc!sewilco
45 03 N  93 08 W [phone]                  ihnp4!meccts!mecc!sewilco
-----

Volume-Number: Volume 7, Number 48

From news  Sat Oct 11 20:23:47 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 12 Oct 86 01:23:34 GMT
Draft-9: job.control

From: [e-mail] (Guy Harris)
Date: Sat, 11 Oct 86 02:29:27 PDT

> > Something like the `pseudo-tty' concept would be very useful:   an  entity
> > which  looks like  a  terminal from one side, but whose behavior is under
> > user-process control from the other side.  Some existing systems do
> > implement such things, but the lack of standardization largely prevents
> > use of them in portable programs.

> One idea would be to put Ritchie's streams in the standard or an extension
> of the standard so that there is a "clean" way of writing user level window
> managers.  Given this there would probably be many window managers
> implemented and likes shells you wouldn't need a single standard one, but
> could provide several and allow users to write their own.

Streams don't in and of themselves provide a "clean" way of writing
user-level window managers.  As Henry pointed out, a pseudo-tty is what you
want here; you have a window manager that simulates a terminal (using a real
terminal or some other sort of display) and provides a tty-like interface to
clients using a pseudo-tty.

Streams might permit a fairly clean implementation of a pseudo-tty, but they
don't provide the only clean way of writing user-level window managers; any
sufficiently powerful pseudo-tty mechanism will do that.  Streams might
provide the cleanest way of providing a sufficiently powerful pseudo-tty
mechanism.

Volume-Number: Volume 7, Number 49

From news  Sat Oct 11 20:27:20 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 12 Oct 86 01:27:08 GMT
Draft-9: job.control

From: [e-mail] (Guy Harris)
Date: Sat, 11 Oct 86 02:49:48 PDT

> "It" is the "virtual console" feature found in most PC-based UNIX
> implementations.  This does rely on memory-mapped video, but character-
> mapped terminals work as well as bit-mapped ones.

No, you don't need a bit-mapped display to do windowing, but I presume most
people already knew that.  Convergent Technologies, for instance, has a
windowing scheme on their PT terminals.  It's not even a "virtual console"
scheme; you can see parts of several windows, if you want.

This sort of windowing mechanism doesn't even necessarily require a
memory-mapped screen; it merely needs a way to redraw a window when it moves
to the front.  Mark Horton's earlier message describes a window manager for
dumb terminals; it even permits more than one window on the screen.

> A process trying to write to a non-current virtual console will (fill
> up some clists and then) block.  A process trying to read the keyboard
> will block until the user switches to its console and types something.

> This is all completely invisible to user programs;  they think they're
> dealing with a perfectly ordinary 24x80 terminal.  No SIGTSTP, no window
> size ioctls, etc.

There's nothing particularly special about all this; other window systems do
the same thing.  Virtual consoles are just a special case of a window system
where all windows cover the full screen.

As for the window size "ioctl", consider this: any program that thinks it's
always dealing with a "perfectly ordinary 24x80 terminal" is going to be
quite surprised when run on an Ann Arbor Ambassador with 60 lines.  Programs
should not make assumptions like that.

Given that the program will then have to query "termcap" or "terminfo" to
find the size of the screen, it's not much trouble to have the routine that
reads in the "termcap" or "terminfo" entry check what the window size
"ioctl" says and only use the value in the entry if the window size is 0x0
(i.e., not specified).  That's what Sun's "termcap" code does.

Volume-Number: Volume 7, Number 50

From news  Sat Oct 11 20:33:14 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 12 Oct 86 01:32:53 GMT
Draft-9: job.control

From: [e-mail] (Guy Harris)
Date: Sat, 11 Oct 86 03:05:09 PDT

> (1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
> acts like a terminal.  This is unquestionably the best, but it
> requires special hardware, and is an area that needs to be
> standardized.

At some point, perhaps.  It's unclear whether now is the time to do so.  I
don't think window systems have been around long enough that people can say
"this is how to do a window system".  I don't think window systems have
settled down enough to start standardizing yet.  (How many people would have
thought of using PostScript as a rendering language for a window system, and
extending it to handle input events as well and act as an extension
language, before James Gosling first talked about his work?  Would people
have missed that entirely when developing a standard?)

Also, what would the standard specify?  A C-language binding to routines to
manipulate the screen?  A set of low-level operations to render images
within a window, a high-level user interface toolkit, something in between,
all of the above, or none of the above?

> (3) Berkeley job control.  Henry may think this is ugly, but from a user's
> point of view, if you can't have a real bitmapped display, this is the
> next best thing.  I strongly prefer it to (2).

For what it's worth, I will point out that even though I have access to (1),
I still use (3).  I haven't analyzed my use of it enough to really say why.
Some of it may be that it takes a while to pop up a new shell window in my
environment (time to start the window process that provides the simulated
terminal and time to start up the Korn shell).  Some of it may be that the
EMACS key bindings I have let me suspend EMACS but not easily fork off a new
shell.  Some of it may be that it is occasionally convenient to move a job
into the background when you discover it'll take a while to complete, or
move a backgrounded job into the foreground to abort it.

> I do think that certain things should be standardized:

> (a) termio, or at least the subset that's commonly used.

The current proposal before 1003.1 does this; it fixes some botches in
"termio" as it exists (MIN and TIME are not overloaded with EOF and EOL, for
instance) and restores a couple of capabilities deleted when the System III
terminal driver first appeared.

> (b) an ioctl to find out the current window size, in chars and pixels.

The current proposal has this, but does not give the window size in pixels.
The "termio" interface is really not a good portable interface for doing
graphics, since most terminals can't do graphics.  As such, it's not clear
why the window size in pixels should be provided by this interface.  A
program that really cares how big the window is in pixels should probably
use the local window system primitives for this, since it has to use the
window system's rendering primitives to draw things anyway.

Volume-Number: Volume 7, Number 51

From news  Sat Oct 11 20:35:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Job control, windows, streams
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 12 Oct 86 01:35:31 GMT
Draft-9: job.control

From: [e-mail] (VLD/VMB)
Date:     Sat, 11 Oct 86 7:06:31 EDT

The current 1003.1 job control proposal is specifically OPTIONAL for
POSIX-conforming systems, partly at my insistence two meetings back.
The idea is to provide a standard for this feature, even though it is
not universal, simply because many vendors feel pressured to provide
Berkeley-style job control.  I believe H-P already has this in their
SVID-compliant system, HP-UX.  Note that the hooks for this are not
quite the same as in 4BSD, due primarily to System V compatibility
constraints.

Several of the recent 1003.1 RFCs and proposals have been aimed at
those areas where traditional AT&T-supplied UNIX has been perceived
as sufficiently weak that other sources (mostly Berkeley) have come
up with features to fill the gap.  These areas include reliable
signals, extent-based file systems, enhanced terminal handler user
interface, and Berkeley-style job control.  Practically all such
ideas have been iteratively discussed and revised before being added
to the POSIX standard document; some are still not adopted but may be
approved for POSIX within a meeting or two.  (I must commend the
committee members and other corporate staff, from H-P and Sun
particularly, who have invested much time in working out the details
of such proposals.)

I hope that the BSD futures planners seriously consider IEEE 1003
compliance for future releases.  That would greatly help their "VAR"
customers (i.e. system vendors) and UNIX programmers in general.
(We have taken quite a bit of trouble to keep BSD systems in mind
when drafting the 1003.1 POSIX standard.)  AT&T's bone-headed SVR3.0
licensing restrictions have suddenly made POSIX conformance an
attractive alternative to SVID compliance in the commercial marketplace,
and it should be obvious why a neutral industry standard would be well
received by government agencies, not to mention by AT&T's competitors.
Support from Berkeley would mean a lot at this stage.

Streams a la DMR would be terrific; however, please keep in mind that
the 1003 WG is not tasked with designing an ideal operating system,
but rather with standardizing a useful interface to a closely related
family of operating systems.  If we strive for the ideal design before
publishing a standard, it will be too late to do any good, and vendors
won't get their systems to conform very soon if ever.  There is room
for future extensions to the standard (which perhaps could be better
structured for this purpose), and indeed there are real-time, signals,
and shell/utility working groups and subcommittees working on some of
these areas already.

As far as multiplexing goes, one can't reasonably leave that to user
mode even with DMR streams; context switching is too expensive.  We've
been running a version of "mpx" (DMD layer host manager) that uses
select() to multiplex in user mode, and it is noticeably slower than
kernel-mode multiplexing.

Volume-Number: Volume 7, Number 52

From news  Sat Oct 11 20:38:32 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix P1003 job control proposal
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 12 Oct 86 01:38:15 GMT
Draft-9: job.control

From: im4u!caip!hplabs!hpda!hpisoa1![e-mail] (Dave Lennert)
Date: Thu, 9 Oct 86 14:06:30 pdt

Attached is the P1003 job control proposal.  The first file contains
the text as accepted at the September P1003 meeting in Palo Alto.
Note that this text sometimes replaces, and sometimes augments,
existing POSIX text.  The second file contains the problems noticed
since then and the proposed resolutions.

    Dave Lennert                ucbvax!hpda!davel               [UUCP]
    Hewlett-Packard - 47UX      ihnp4!hplabs!hpda!davel         [UUCP]
    19447 Pruneridge Ave.       hpda![e-mail]         [ARPA]
    Cupertino, CA  95014        [phone]                  [AT&T]


# This is a shell archive.  Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by davel at hpisoa1 on Thu Oct  9 13:23:24 1986
#
# This archive contains:
#    acceptedtext    problems
#

echo x - acceptedtext
cat >acceptedtext <<'@EOF'
                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       2.3  General Terms
       Replace or add the following definitions:


       job control option
         Job control allows    users to selectively stop (suspend)
         the execution of processes    and continue (resume) their
         execution at a later point.  The user typically
         employs this facility via the interactive interface
         jointly supplied by the terminal I/O driver and a
         command interpreter.  Conforming implementations may
         optionally    support    job control facilities (see
         Symbolic Constants      2.10).  Portions of the standard
         operating system interface    which are required only    on
         implementations which support the job control option
         are so labelled.


       process group leader
         A process group leader is a process whose process ID
         is    the same as its    process    group ID.  Any process that
         is    not a process group leader may detach itself from
         its process group and becomes the process group leader
         of    a new process group by calling either the setpgrp()
         or    setpgrp2() function, which can cause a process to
         become either a session process group leader or a job
         process group leader, respectively.  Job process group
         leaders can exist on implementations which    support    the
         job control option.


       saved process group ID
         An    active process has a saved process group ID that is
         set to the    saved process group ID of the parent
         process at    the time of creation of    the process (via
         the fork()    function).  It is reset    to the process
         group ID of the process when the process successfully
         calls one of the exec functions.


       2.10  Symbolic Constants
       Add the following new constant after the    IEEE1003 constant
       defintion:


       IEEE1003job
         If    this symbol is defined then the    implementation
         supports the job control option.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       3.2.1  Wait for Process Termination
       Functions: wait(), wait2()

       3.2.1.1    Synopsis
       Add the following at the    end of the section:

         #include <sys/wait.h>
         int wait2 (stat_loc, options)
         int *stat_loc;
         int options;

       3.2.1.2    Description
       Add the following at the    end of the section:

       If the wait2() variant is used, then there are two options
       available for modifying the behavior of the system call.
       They may    be combined by oring them together.  The first is
       WNOHANG which prevents wait2() from suspending the calling
       process even if there are children to wait for.    In this
       case, a value of    zero is    returned indicating there are no
       children    which have stopped or died.  If    the second option
       WUNTRACED is set, wait2() will also return information when
       children    of the current process are stopped because they
       received    a SIGTTIN, SIGTTOU, SIGTSTP, or    SIGSTOP    signal.

       The wait2() function is provided    if the implementation
       supports    the job    control    option.

       3.2.1.3    Returns
       Add the following at the    end of the section:

       If wait2() is called, the WNOHANG option    is used, and there
       are no stopped or terminated children, then a value of zero
       is returned.  Otherwise,    a value    of -1 is returned and errno
       shall be    set to indicate    the error.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       In section 3.2.2.2 Description of the _exit function replace
       the paragraph:

         If    the process is a process group leader, the SIGHUP
         signal may    be sent    to each    process    that has a process
         group ID equal to that of the calling process.

       with:

         If    the process is a session process group leader, the
         SIGHUP signal may be sent to each process that has    a
         process group ID equal to that of the calling process;
         also, all such processes may have their process group
         ID    set to zero.

         If    the implementation supports the    job control option
         and if the    calling    process    has child processes that
         are stopped, they will be sent SIGHUP and SIGCONT
         signals.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       3.3.1  Signal Names

       3.3.1.2    Description
       Add the following at the    end of the signals list.

       SIGCLD    +   child process terminated

       If the implementation supports the job control option then
       the following are defined:

       SIGSTOP     #    stop (cannot be caught or    ignored)
       SIGTSTP     #    stop signal generated from keyboard
       SIGTTIN     #    background read attempted    from control terminal
       SIGTTOU     #    background write attempted to control terminal
       SIGCONT     %+   continue after stop

      +  Indicates that the    action on SIG_DFL is to    ignore the
         signal, rather than terminate the process.

      #  Indicates that the    action on SIG_DFL is to    stop rather
         than terminate the    process.

      %  Indicates that the    signal will not    be held    off by a
         stopped process.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       In section 3.3.2.2 Description of the kill() function, add
       the following paragraph at the end of the Description
       section.

       As a single special case    on implementations that    support    the
       job control option, the continue    signal SIGCONT can be sent
       to any process that is a    descendant of the current process.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       3.3.3  Signal Processing

       3.3.3.2    Description
       Replace the SIG_DFL and SIG_IGN discussions with    the
       following text.    (Note that this    text needs rewording based
       on the signal working group decisions from Palo Alto, 9/86.
       Bob Lenk    is planning on merging this text with the proposal
       he sends    you.  So you should only have to verify    that he    has
       done this.)

       SIG_DFL - signal    specific default action
         For all signals listed in the table in <signal.h>
         3.3.1, unless otherwise indicated the default action
         is    either simple abnormal termination or abnormal
         termination with actions of the receiving process.
         The result    of abnormal termination    with actions is
         implementation-dependent.    Abnormal termination with
         actions may result    in the creation    of a file named
         core in the receiving process's current directory.
         Such a core file should contain sufficient    information
         to    document the state of the process at the time of
         the signal.

         For certain indicated signals listed in the table in
         <signal.h>      3.3.1, the default action is to stop
         (suspend) the receiving process.  While a process is
         stopped, any additional signals that are sent to the
         process will be held off until the    process    is
         continued.     An exception to this is SIGCONT which
         always causes the receiving process to continue if    it
         is    stopped.  When a process is continued, pending
         signals will be processed.

         For certain indicated signals listed in the table in
         <signal.h>      3.3.1, the default action is to ignore
         the signal.

         Signals not described <signal.h>    3.3.1 may have
         other default actions.

       SIG_IGN - ignore    signal
         The signal    sig is to be ignored.  The signals SIGKILL
         and SIGSTOP shall not be ignored.    Ignoring SIGCLD    may
         cause terminating children    to be ignored by the wait
         functions     3.2.1.

       At the end of the "function address - catch signal"
       discussion, replace the statement:

       The signal SIGKILL cannot be caught.

       with:

       The signals SIGKILL and SIGSTOP cannot be caught.

       3.3.3.4    Errors
       Replace:

       [EINVAL]    The value sig is either    an illegal signal number or
         SIGKILL.

       with:

       [EINVAL]    The value sig is either    an illegal signal number,
         or    is equal to SIGKILL or SIGSTOP.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       Replace all of section 4.3.1 with:



       4.3.1  Get Process Group    ID
       Functions: getpgrp(), getpgrp2()

       4.3.1.1    Synopsis

         int getpgrp ( )

         int getpgrp2 (pid)
         int pid;

       4.3.1.2    Description
       The getpgrp() function returns the process group    ID of the
       calling process.

       The getpgrp2() function returns the process group ID of the
       specified process.  If pid is zero, the call applies to the
       current process.     For this to be    allowed, the real or
       effective user ID of the    current    process    must match the real
       or effective user ID of the referenced process, the
       effective user ID of the    current    process    must be    super-user,
       or the referenced process must be a descendant of the
       current process.     The saved set-user ID of the referenced
       process may be checked in place of its effective    user ID.

       The getpgrp2() function is provided if the implementation
       supports    the job    control    option.

       4.3.1.3    Returns
       The getpgrp() function returns the process group    ID of the
       calling process.

       Upon successful completion, the getpgrp2() function returns
       the process group ID of the specified process.  Otherwise a
       value of    -1 is returned and errno is set    to indicate the
       error.

       4.3.1.4    Errors
       If the getpgrp2() function returns -1, the value    stored in
       errno may be interpreted    as follows:

       [EPERM]       The effective user ID of the    current    process    is
           not super-user, the real or effective user ID of
           the current process does not    match the real or
           effective user ID (or saved set-user    ID) of the
           specified process, and the specified    process    is
           not a descendant of the current process.

       [ESRCH]       No process can be found corresponding to that
           specified by    pid.

       4.3.1.5    References
       setpgrp()   4.3.2, signal()   3.3.3.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       Replace all of section 4.3.2 with:



       4.3.2  Set Process Group
       Functions: setpgrp(), setpgrp2()

       4.3.2.1    Synopsis

         int setpgrp ( )

         int setpgrp2 (pid, pgrp)
         int pid, pgrp;

       4.3.2.2    Description
       The setpgrp() function sets the process group ID    of the
       calling process to the process ID of the    calling    process    and
       returns the new process group ID.  The calling process
       becomes a session process group leader.

       The setpgrp() function relinquishes the process's
       controlling terminal unless the process is already the
       process group leader.

       The setpgrp2() function sets the    process    group ID of the
       process specified by pid    to be pgrp.  If    pid is zero, the
       process group ID    of the calling process will be affected.
       If the affected process's new process group ID is the same
       as its process ID then the affected process becomes a job
       control process group leader.

       The setpgrp2() function does not    affect the process's
       controlling terminal.

       The setpgrp2() function is provided if the implementation
       supports    the job    control    option.

       The following condition must be met for the setpgrp2()
       function    to succeed; otherwise, the error [EINVAL] is
       returned:

        The    value of pgrp must be in the range of valid process
        group ID values, or    it must    be zero    ("no process
        group").

       In addition, one    or more    of the following conditions must be
       met for the setpgrp2() function to succeed; otherwise, the
       error [EPERM] is    returned:

        The    effective user ID of the calling process is super-
        user.

        The    affected process is a descendant of the    calling
        process.

        The    real or    effective user ID of the calling process
        matches the    real or    effective user ID of the affected
        process.  The saved    set-user ID of the affected process
        may    be checked in place of its effective user ID.

       In addition, one    or more    of the following conditions must be
       met for the setpgrp2() function to succeed, otherwise, the
       error [EPERM] is    returned:

        The    effective user ID of the calling process is super-
        user.

        The    value of pgrp matches the saved    process    group ID of
        the    calling    process.

        All    processes with a process ID or process group ID
        that is the    same as    pgrp have the same real    or
        effective user ID as the real or effective user ID of
        the    calling    process, or are    descendants of the calling
        process.  The saved    set-user ID of the related
        processes may be checked in    place of their effective
        user ID.

       4.3.2.3    Returns
       The setpgrp() function returns the value    of the new process
       group ID.

       Upon successful completion, the setpgrp2() function returns
       a value of 0.  Otherwise, a value of -1 is returned and
       errno is    set to indicate    the error.

       4.3.2.4    Errors
       If the setpgrp2() function returns -1, the value    stored in
       errno may be interpreted    as follows:

       [ESRCH]       No process can be found corresponding to that
           specified by    pid.

       [EPERM]       The effective user ID of the    calling    process    is
           not super-user; and the real    or effective user
           ID of the calling process does not match the
           real    or effective user ID (or saved set-user    ID)
           of the specified process; and the specified
           processes are not descendants of the    calling
           process.

       [EPERM]       The effective user ID of the    calling    process    is
           not super-user; and the value pgrp does not
           match the saved process group ID of calling
           process; and    a process exists that is not a
           descendant of the calling process and whose
           process ID or process group ID match    pgrp, while
           neither the real or effective user ID (or saved
           set-user ID)    of this    process    match either the
           real    or effective user ID of    the calling
           process.

       [EINVAL]       The value for pgrp is outside the range of valid
           process group ID values and is non-zero.

       4.3.2.5    References
       exec   3.1.2, _exit()   3.2.2, fork()   3.1.1, getpid()
       4.1.1, kill()   3.3.2, signal()     3.3.3.

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

                                   IEEE
       SYSTEM FOR COMPUTER ENVIRONMENTS             Std 1003.1

       Alter the forthcoming reliable signals proposal,    the
       sigvector() description,    by adding the following    paragraph:

       The sv_flags field can be used to modify    the receipt the
       specified signal.  If sig is SIGCLD and the implementation
       supports    the job    control    option,    the following flag bit can
       be set in sv_flags:

      SV_CLDSTOP   Also generate SIGCLD when children stop

@EOF

chmod 664 acceptedtext

echo x - problems
cat >problems <<'@EOF'
There are two omissions in the job control specification that
have come to light since it was accepted at the P1003 meeting
in Palo Alto.  There will be forthcoming proposals to correct
these.

Omission 1:

Bob Lenk noticed that, in adding SIGCLD to the required portion of
POSIX, we neglected to deal with the issue of what happens when
SIGCLD is set to SIG_IGN.  Specifically, on ATT this causes
terminated children to be invisible to wait*() while on BSD there
is no such side effect.  Bob Lenk feels the best way to handle this
is to disallow conforming applications from setting SIGCLD to SIG_IGN.
(There is no advantage to using SIG_IGN over SIG_DFL in the case
of SIGCLD anyway.)  Bob is planning on submitting a cleanup proposal
proposing this.

Omission 2:

Doug Gwyn pointed out the following omission:

The changes to section 3.2.1.2 for wait2() did not contain a
description of the returned status information in the case
of stopped children.

I've submitted a proposal to add the following additional text:

[OLD TEXT FOR CONTEXT:]

wait2() will also return information when children of the
current process are stopped because they received a SIGTTIN,
SIGTTOU, SIGTSTP, or SIGSTOP signal.

[NEW TEXT:]

In this case, the status information can also be interpreted
in the following way:

    If the child process stopped, the 8 bits of status
    (corresponding to the octal value 0177400) will contain
    the number of the signal that caused the process to
    stop and the low order 8 bits corresponding to the
    octal value 0377 will be set equal to the octal value
    0177.
@EOF

chmod 664 problems

exit 0


Volume-Number: Volume 7, Number 53

From news  Sat Oct 11 20:45:09 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 12 Oct 86 01:44:47 GMT
Draft-9: job.control

From: hplabs!hpda!hpisoa1!davel (Dave Lennert)
Date: Thu, 09 Oct 86 22:33:31 -0800

As an addendum to the P1003 job control proposal text I submitted,
here's a paper describing the 4.2 job control implementation, the
System V incompatibilities, and how they were resolved.  This was
the background investigation that went into the P1003 proposal.

This is the same paper that appears in the Atlanta USENIX proceedings.
[ June 1986, pp. 459-474.  -mod ]
It uses the -ms macro package.

    Dave Lennert                ucbvax!hpda!davel               [UUCP]
    Hewlett-Packard - 47UX      ihnp4!hplabs!hpda!davel         [UUCP]
    19447 Pruneridge Ave.       hpda![e-mail]         [ARPA]
    Cupertino, CA  95014        [phone]                  [AT&T]


# This is a shell archive.  Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by davel on Thu Oct  9 22:29:34 PDT 1986
# Contents:  jobpaper.ms

echo x - jobpaper.ms
sed 's/^@//' > "jobpaper.ms" <<'@//E*O*F jobpaper.ms//'
@.de PB
@.sp 1
@.RS
@.nf
@..
@.de PE
@.fi
@.RE
@.sp 1
@..
@.DA
@.    \" Put page numbers at bottom center rather than top center
@.rm CH
@.ds CF - \\n(PN -
@.    \" UX - UNIX macro
@.de UX
@.ie \\n(UX \s-1UNIX\s0\\$1
@.el \{\
\s-1UNIX\s0\\$1\(dg
@.FS
\(dg \s-1UNIX\s0 is a trademark of AT&T.
@.FE
@.nr UX 1
@.\}
@..
@.TL
A System V Compatible Implementation of 4.2BSD Job Control
@.AU
David C. Lennert
@.AI
Hewlett-Packard Company
Information Technology Group
hplabs\^!\^hpda\^!\^davel
@.AB
This paper gives an overview of how process groups and controlling
terminals are handled in System V and 4.2BSD and then
discusses the effect 4.2BSD job control has on these things.
A modified 4.2BSD interface is discussed which supports 4.2BSD job control
functionality but in a way which allows AT&T System V compatibility.
This interface has been implemented in Hewlett-Packard's
@.UX
system, HP-UX.
@.AE
@.sp 1
@.NH
INTRODUCTION
@.PP
The job control functionality first introduced into
@.UX
by Jim Kulp of IIASA and later provided by 4.2BSD
@.UX
has become a \fIde facto\fP industry standard.
However, this job control facility, as implemented in 4.2BSD, is incompatible
in several respects with System V.
@.PP
Recently a proposal was submitted to the IEEE P1003 Portable Operating
System standard committee by Sun Microsystems [Harris86] which attempts
to define
4.2BSD job control functionality in a way compatible with System V.
Hewlett-Packard Company has been independently developing a similar
proposal.  HP's proposal is almost identical to Sun's but goes
beyond it to address many "corner case" areas which strongly affect
System V compatibility.
@.PP
This paper gives an overview of the relevant areas of System V
functionality which are affected.  It then overviews how job control
is implemented in 4.2BSD and how this impacts the System V interface.
Finally, the HP-UX interface is presented and a similar overview of its
implementation is given.
@.PP
The various overviews cover how job control signals are generated, passed,
and acknowledged by the tty driver and user processes.  They also explain
how process groups are established and changed.
@.sp 1
@.NH
FUNDAMENTALS
@.PP
In the following discussion the reader is assumed to have an understanding
of several fundamental concepts found in the
@.UX
operating system.  For convenience these concepts are briefly reviewed here.
@.NH 2
Process Groups and Controlling Terminals
@.PP
Every process has a unique numeric value associated with it called
its \fIprocess ID\fP.  Every process also has a non-unique numeric value
associated with it called its \fIprocess group ID\fP.
A \fIprocess group\fP is a collection of processes having identical numeric
process group ID's.  Typically, one process in the process group will
be the \fIprocess group leader\fP.  The process group leader has a process ID
which is numerically equal to the process group ID associated with all processes
in the process group.  Typically, the process group leader is the ancestor
of all other processes in the process group.
@.PP
A process can have a \fIcontrolling terminal\fP which is usually the login
terminal of the user who created the process.  A process can obtain access
to its controlling terminal by opening the file \fI/dev/tty\fP.
All processes in the same process group typically share the same controlling
terminal.  A terminal usually has a process group ID associated with it,
called the \fItty group ID\fP.  When a user generates a keyboard signal
(e.g., by typing the interrupt character), the tty driver sends the appropriate
signal to all processes which are members of the process group indicated by
the tty group ID.
In summary,
usually, but not necessarily, all processes in the same process group share
the same controlling terminal, and the tty group ID for that terminal is
equal to the process group ID of the process group.
@.PP
For further explanation see [Roch85] and intro(2) in your favorite
@.UX
Programmer's Manual.
@.NH 2
4.2BSD Job Control
@.PP
4.2BSD job control allows users to selectively stop (suspend) the
execution of processes and continue (resume) their execution at any
later point.  This only easily works for processes which are stopped
and continued during the same login session.
@.PP
The user almost always employs this facility via the interactive interface
jointly supplied by the system tty driver and a job control shell such as
csh(1) or ksh(1).
The tty driver recognizes a user-defined
\fIsuspend character\fP which causes all current foreground processes to
stop and the user's job control shell to resume.
The job control shell provides commands which continue stopped processes
in either the foreground or background.
The tty driver will also stop a background process when it attempts to
read from or write to the users terminal.  This allows the user to finish
or suspend their foreground task without interruption and continue the
stopped background process at a more convenient time.
@.PP
To enable the system to support this,
4.2BSD job control introduces five new signals: SIGSTOP, SIGTSTP, SIGTTIN,
SIGTTOU, and SIGCONT.  The first four signals cause a process to stop unless
the signals are being caught or ignored.  SIGCONT always causes a stopped
process to continue.  (SIGCONT has no effect on processes which are not
stopped.)  SIGSTOP cannot be caught or ignored.
@.PP
The tty driver sends some of these signals to all processes in the tty
process group under the following conditions:  The driver sends SIGTSTP when
the user types the suspend or delayed suspend character.  The driver sends
SIGTTIN (SIGTTOU) when a background process attempts to read from (write to)
its controlling terminal.
SIGCONT is usually only sent by a job control shell when
the user requests that a stopped process be continued.
Of course, any signal can be sent by a user via the kill(1) command or
by a program via the kill(2) system call.
@.PP
It should be noted that these signals can be added to a
@.UX
implementation in a manner which preserves source and object code
compatibility.  A process is not required to be aware of them.  By
default the signals do "the right thing."
@.PP
For further information see [Joy80] and [UCB83].
@.sp 1
@.NH
AT&T SYSTEM V
@.NH 2
Introduction
@.PP
System V process groups closely resemble the concept of a login session.
That is, all processes spawned during the same login session tend to
belong to the same process group, and keyboard signals are typically
sent to all processes spawned from the login session.
@.NH 2
System V Process Group Handling
@.PP
In System V, the only way to alter the process group associated
with a process (p_pgrp) is via setpgrp(2).  And this can only set the process
group to equal the process ID (pid) of the process.  When this happens
the resulting process with pid = p_pgrp is called a process group leader.
Since a process's pid can never change,
once a process issues a setpgrp(2) call it irrevocably becomes
a process group leader.
@.PP
The init(1M) process spawns all other processes on the system either
directly or indirectly.  Before directly spawning a process
(after the fork(2) but before the exec(2)),
init calls setpgrp(2).
Thus all original children (not orphans) of init are forced to (irrevocably)
be process group leaders.
@.PP
When a new process is created, it is assigned a new pid but it inherits
the process group number of its parent.  Thus child processes are, by
default, not process group leaders (although they can become a process
group leader via setpgrp(2)).
@.PP
When a process group leader which has a controlling terminal (see below)
terminates, SIGHUP is sent to all processes in the same
process group.
@.PP
Further, when a process group leader terminates, all processes that
belong to this process group are altered to belong to no process group
(their p_pgrp is set to zero).
More precisely, when any process exits, all processes whose process
group (p_pgrp) equals the pid of the terminating process will have their
p_pgrp set to zero; this check succeeds only in the case of a
terminating process group leader.
@.NH 2
System V Controlling Terminals
@.PP
A terminal that is currently open by a process may also be a "controlling
terminal" for a process group.  When certain
control characters are typed on a controlling terminal, signals are
sent by the terminal driver to all processes that belong to the process
group associated with the terminal.
@.PP
When a process becomes a process group leader (via setpgrp(2)) it
automatically loses its controlling terminal.  After this,
the first terminal (that is not already a controlling terminal)
opened by the process
is assigned to be the controlling terminal for that process.
Also, the process group associated with that terminal (t_pgrp, also known
as the tty group ID) is set
equal to the process group associated with the process group leader
(p_pgrp).
All child processes inherit the controlling terminal and
process group of their parent.
@.PP
More precisely, in System V, the process group associated with a
terminal (t_pgrp), can be changed in the following ways:
@.IP (1)
When a terminal is opened by a process group leader (pid == p_pgrp)
that does not already have a controlling terminal,
it becomes the controlling terminal for that process group
(t_pgrp is set equal to p_pgrp) if it is not already a controlling
terminal.
@.IP (2)
When a process group leader (pid == p_pgrp) dies, if it has a
controlling terminal that is associated with the same process
group (t_pgrp == p_pgrp), then that terminal is disassociated from that
process group (t_pgrp is set to zero).
@.IP (3)
When the last process to have a terminal open closes that terminal,
the terminal is disassociated from its process group (t_pgrp
is set to zero).
@.NH 2
System V Typical Scenario
@.PP
This is a typical scenario for the birth and death of a process group and
its controlling terminal.
@.PP
The init(1M) process wants to enable a terminal for login.  It calls fork(2)
to create a new process and then calls
setpgrp(2) to make the process a process
group leader which also removes the process's controlling terminal.  It
then runs the getty(1M) program as the process via exec(2).
Getty opens the terminal causing it to become getty's controlling terminal
and be associated with getty's process group (t_pgrp is set to p_pgrp).
Getty replaces itself with login(1) which replaces itself with a login
shell, e.g., sh(1).
Usually no program calls setpgrp(2) and thus all descendent processes
of the login shell are in the same process group and have the same
controlling terminal; keyboard signals are sent to all processes launched
during this session.
@.PP
When a logout occurs, the login shell (which is the process group leader)
dies and the controlling terminal is freed up (t_pgrp is set to zero) so
that it can be claimed as a controlling terminal by a subsequent getty
respawned by init.
SIGHUP is sent to all processes in the same process group.
The process group (p_pgrp) of all descendent processes is then set to zero.
@.PP
Note that there may continue to be background processes (previously
started by the
now defunct login shell) which continue to execute but
keyboard signals will no longer be sent to these processes (since
both t_pgrp and p_pgrp equal zero).
@.sp 1
@.NH
4.2BSD
@.NH 2
Introduction
@.PP
4.2BSD process groups closely resemble the concept of a task within
a login session, where a task represents a set of processes which
are affected as a group by job control operations.
Every time a job control shell (e.g., csh) spawns either a foreground
or background command, all processes in the pipeline (and their
descendents) are placed in their own unique process group with the
first command in the pipeline being the process group leader.
@.PP
A task is in the foreground when the process group associated with the
controlling terminal for the task (t_pgrp) is equal to the process
group associated with the processes in the task (p_pgrp).
Otherwise the task is in the background.
A job control shell moves a job between the foreground and background
by adjusting the terminal process group (t_pgrp) of the controlling
terminal.
@.PP
Note that 4.2BSD forms new process groups with process group leaders
much more often than System V usually does (every command versus
every login).
@.NH 2
4.2BSD Process Group Handling
@.PP
In 4.2BSD, the process group associated with a process (p_pgrp)
can be altered in two ways.  The first is via setpgrp(2).  4.2BSD's setpgrp(2)
is analogous to System V's setpgrp(2) except that the former can affect
processes other than the current process and can cause the affected
process to adopt a process group other than that process's process ID (pid).
Thus, unlike System V, a process can cease to be a process group leader.
@.PP
In addition to setpgrp(2), a process that is not a member of any
process group (p_pgrp == 0) will "inherit" or join the process
group associated with its controlling terminal at the time the
process is assigned a controlling terminal during open(2).
If the terminal being opened is not presently the controlling
terminal for any process group, then the process opening the
terminal will first be made a process group leader (p_pgrp will
be set to p_pid) and then the terminal will become the controlling
terminal for this new process group.  All this is done by the
tty open code.
@.PP
When a new process is created it inherits the process group of its parent.
@.PP
Unlike System V init(1M), 4.2BSD init(8) does not call setpgrp(2) when spawning
other processes.  All processes spawned by init inherit init's process
group which happens to be zero ("not a member of any process group").
This is actually crucial for assigning controlling terminals; see below.
@.NH 2
4.2BSD Controlling Terminals
@.PP
Unlike System V, a 4.2BSD process does not lose its controlling terminal
when altering its process group (via setpgrp(2)).
Also unlike System V, a 4.2BSD process that is a process group leader
(pid == p_pgrp) but which has no controlling terminal does not receive
a controlling terminal when opening a new terminal.
@.PP
A process can obtain a controlling terminal under 4.2BSD in only the
following ways:
@.IP (1)
A process can inherit a controlling terminal from its parent.
@.IP (2)
A process that is not a member of any process group (p_pgrp == 0)
can open any terminal and that terminal will become its controlling
terminal (whether or not it is already the controlling terminal for another
process).
However, this can happen in one of two ways:
@.IP
If the terminal is not already a controlling terminal (t_pgrp == 0)
then the opening process becomes a process group leader (its p_pgrp is set
equal to its pid) and the terminal becomes its controlling terminal
(t_pgrp is set to the new p_pgrp value).
@.IP
If the terminal is already a controlling terminal for another process
(t_pgrp is not zero) then the opening process joins the process group
already associated with the controlling terminal.  That is, p_pgrp is
set equal to the current t_pgrp.  Note that the opening process does
not become a process group leader, i.e., p_pgrp is not equal to its pid.
@.IP
Note that this procedure only happens during the first terminal open
for a process that was either originally spawned by init or whose
ancestor processes (all the way back to init) never altered their
process group (p_pgrp) either by opening a terminal or calling setpgrp(2).
@.PP
A terminal ceases to be a controlling terminal (t_pgrp is set to zero) under
4.2BSD in the following way:
@.IP (1)
When the last process to have a terminal open closes that terminal
then the terminal is disassociated from its process group (t_pgrp
is set to zero).
@.PP
There are two other facilities unique to 4.2BSD which affect access to
control terminals: the TIOCSPGRP ioctl(2) and vhangup(2).
@.PP
The TIOCSPGRP ioctl(2) function changes a terminal's process group (t_pgrp)
to any desired value.
It is typically used by csh(1) to control which set of processes (process
group) is in the foreground.
@.PP
The vhangup(2) function is invoked by init after
forking but before exec'ing getty.  This function removes read and
write permission for all processes (including the caller)
that have the controlling terminal
open (whether or not it is their controlling terminal).  It then sends
SIGHUP to the process group associated with the terminal (t_pgrp).
The latter action is similar to the System V functionality that sends
SIGHUP to a process group on death of the process group leader; 4.2BSD
does not do this on the death of a process group leader.
@.NH 2
4.2BSD Typical Scenario
@.PP
This is a typical scenario for the birth and death of a login, its
controlling terminal, and process groups associated with a job.
@.PP
The init(8) process wants to enable a terminal for login.
First it creates a new process via fork(2).
Then it opens the terminal which
(because the p_pgrp inherited from init is zero)
causes it to become the controlling
terminal for this process and either alters the process group (p_pgrp) of
the process to match the terminal process group (t_pgrp) if non-zero, or
alters both p_pgrp and t_pgrp to equal the process ID (pid) if t_pgrp is zero.
At this point the new process has a controlling terminal whose process group
(t_pgrp) is equal to the process's process group (p_pgrp).  However, the
process may not be a process group leader (i.e., p_pgrp may not equal pid).
@.PP
Now the new process calls vhangup(2) to remove
access permissions for the controlling terminal from all processes (as well
as sending SIGHUP to any processes in the process group previously
associated with the terminal).
The new process then reopens the terminal to get a file descriptor with
read and
write permissions since the vhangup(2) removed these permission from the
file descriptor returned by the previous open.
The previous file descriptor is not closed until now to prevent losing
the controlling terminal; (remember that p_pgrp for the new process is
no longer zero.)
@.PP
The new process now replaces itself with getty(8) which replaces itself
with login(1) which replaces itself with a login shell, e.g., csh(1).
Csh now begins to manipulate the process group associated with the
terminal (t_pgrp) via the TIOCSPGRP and TIOCGPGRP ioctl(2) calls and
the process group associated with its child processes (p_pgrp) via
setpgrp(2) in order to allow job control.  This happens (briefly) in the
following way:
@.PP
Csh launches a pipeline by making all programs in the pipeline be
immediate descendents of csh.  (This is different from sh which makes
all programs in the pipeline except the last be descendents of the
last program in the pipeline.)
All programs in the pipeline belong to the same process group (not the
same as csh's process group) and the first program in the pipeline is
the process group leader (its pid is equal to the process group for the
pipeline).
If the pipeline is being launched in the foreground (or moved to the
foreground) then the process group associated with the terminal (t_pgrp)
is set to the process group of the pipeline.
@.PP
When a logout occurs, the login shell dies.
Any pending SIGTTIN, SIGTTOU, and SIGTSTP signals are cleared for all
descendent processes.
All immediate child processes are inherited as orphans by init; if any are
currently stopped then they are killed (SIGKILL).
If the exiting process is the last process that has the controlling
terminal open then the terminal's process group (t_pgrp) is set to zero,
otherwise it is left alone.
Nothing special is done for process group leaders; in fact, login shells
are frequently not process group leaders.  (SIGHUP is not sent and the
controlling terminal is not necessarily cleared.)
@.PP
Note that there may continue to be processes (previously
started by the now defunct login shell) which continue to execute.
And that keyboard signals can still be sent to these processes under some
circumstances (specifically when the processes were in the foreground
(p_pgrp == t_pgrp) when the login shell died; this usually only happens
when the login shell is killed from another terminal via kill(1).)
Note also that this continues to be true even after a new session logs in
on the same terminal since the new login shell joins the process group
which is already associated with the terminal from the prior login.
@.NH 2
Job Control Signal Handling
@.PP
The following discussions concerning signals and kernel process
synchronization are similar to ones found in [Thom78], [Ritch79],
and [Bach79].
@.NH 3
Basic Overview
@.PP
Usually a process is either running or sleeping waiting for an event to
occur (e.g., I/O completion).  When a signal is sent to a process (either
by another process or an I/O driver) what actually occurs is that a flag
is set for the receiving (or target) process indicating that the signal
has been sent and the target process performs the actual signal operation
to itself the next time it runs.  Thus sending a signal amounts to
requesting the target process to itself perform a particular action.
If the target process is already running it is interrupted to process
the signal.  If it is runnable but not currently running then the
system merely waits for it to become the currently running process at
which point the signal is acknowledged.  If the target process
is sleeping then either
it is moved into a runnable state (if it is sleeping at an "interruptable"
priority) or it is left sleeping (at an "uninterruptable" priority) and
the signal is not acknowledged until the slept on event occurs.
@.PP
The kernel procedure which sends a signal is psignal() and is executed
by the sending process or driver.
Psignal() updates a list of pending signals for the receiving process.
If the receiving process is the currently running process and it is
executing in kernel mode then the pending signal is acknowledged
when the current system call completes.
(This is the case where the sending process and the receiving process
are the same.)
If the receiving process is the currently running process and it is
executing in user mode then a special event is generated
which causes the process to
enter the kernel and acknowledge the pending signal.
(This is the case where the sending "process" is really an interrupt
handler which, for example, is servicing an interrupt character
typed on a user's terminal.)
If the receiving process is
sleeping but not holding off signals then it is set running via wakeup();
the pending signal is acknowledged as soon as the receiving process executes.
If the receiving process is suspended in a sleep state that holds off
signals ("sleeping uninterruptably") then it is left sleeping;
the pending signal will be acknowledged after the waited for event occurs.
@.PP
The procedure which tests for a pending signal is issig() and is executed
by the receiving process.
Issig() is executed whenever the receiving process changes from kernel
mode to user mode execution; for example, at the completion of a system call.
It is also executed whenever the receiving process is awakened from
being suspended in a sleep state that does not hold off signals ("sleeping
interruptably").
@.PP
The procedure which performs the requested signal operation (e.g.,
invoking a signal handler or killing the process) is psig() and is
executed by the receiving process if issig() returns true.
@.PP
This basic structure is essentially the same in System V, 4.2BSD, and
HP-UX.  However, under 4.2BSD-style job control, these general principles
can work slightly differently:
@.PP
When processing stop signals,
the psignal() function, called by the sending process, actually stops
the target process sometimes.  In these cases, the target process
never realizes that it received the signal or that it stopped.
However, in other cases, psignal() performs the usual process of
setting the flag (p_sig) requesting
that the target process stop itself the next time it runs.
@.PP
The issig() function, called by the target process, can actually stop the
target process.
@.PP
The psig() function is only called in the case where a user handler
has been provided for the job control signal.
@.PP
A more complete description of job control signal handling is contained
in the pseudocode below.
@.NH 3
psignal()
@.PP
To send SIGCONT to a target process:
@.PB
sending SIGCONT clears any pending stop signals;
if the target process is STOPPED but is also SLEEPING (p_wchan != 0)
    merely continue the process's SLEEP;

else if the target process is STOPPED and is NOT SLEEPING (p_wchan == 0)
    set the process RUNNING;
@.PE
@.PP
To send a stop signal (SIGTSTP, SIGTTIN, SIGTTOU, SIGSTOP) to a target process:
@.PB
sending a stop signal clears any pending SIGCONT;

if the target process is RUNNABLE or RUNNING
    note the pending signal in p_sig;

else if the target process is SLEEPING NON-interruptably
    note the pending signal in p_sig;

else if the target process is SLEEPING interruptably
     and IS catching the signal
    note the pending signal in p_sig and
    wakeup the process from its sleep;

else if the target process is SLEEPING interruptably
     and is NOT catching the signal
    stop the process by setting its state to SSTOP
    but leave it sleeping on its p_wchan;
    send SIGCLD to parent (if it expects BSD-style)
@.PE
@.PP
General note: sending a stop signal (other than SIGSTOP) to a child
of init causes the target process to be killed.
@.NH 3
issig()
@.PP
Issig() is called in all cases except where the process was
sleeping interruptably and was not catching the signal.
@.PP
To acknowledge a pending SIGCONT or stop signal:
@.PB
if in the middle of a VFORK
    hold off all stop signals (pretend they don't exist yet)

else if catching the signal
    return a request to invoke user signal handler via psig()

else if SIGCONT
    do nothing  /* pretend it doesn't exist */

else /* stop signals */
    stop the process by setting its state to SSTOP
    send SIGCLD to parent (if it expects BSD-style)
    call swtch() to dispatch another process
@.PE
@.PP
General note: sending a stop signal (other than SIGSTOP) to a child
of init causes the target process to be killed.
@.NH 3
psig()
@.PP
Psig() is called whenever issig() returns an indication
that a user handler is defined for a job control signal.
Psig() merely invokes the user signal handler.
@.NH 3
wakeup()
@.PP
The fact that a process is sleeping (waiting for an event to occur)
is indicated by two process state values:  p_wchan is non-zero,
indicating the event being waited for, and the process state is SSLEEP.
@.PP
Wakeup() usually causes all processes waiting (sleeping) on a specified
event to be awakened.  When a process is awakened two things
happen:  The process is removed from the sleep queue (p_wchan is cleared)
and it is added to the run queue.
@.PP
If, however, wakeup() discovers a process whose p_wchan matches the
specified event but whose process state is SSTOP (stopped) then
the process is removed from the sleep queue (indicating that the
waited for even has happened) but it is not placed on the run queue.
A subsequent SIGCONT will cause it to be placed on the run queue.
@.PP
Thus it is possible to have a process which is both sleeping (p_wchan
non-zero) and stopped (process state is SSTOP rather than SSLEEP).
@.NH 3
Signal Setup via init
@.PP
When init(8) launches any process it causes the process to ignore all
the job control stop signals (SIGTSTP, SIGTTIN, & SIGTTOU).  This allows
login shells which are not job control shells to automatically ignore
the signals.  Further, all descendent processes of such a login shell
will also ignore these signals unless they explicitly enable them.
@.NH 2
Foreground/Background Processes
@.NH 3
Basic Overview
@.PP
4.2BSD job control supports the notion of a process being in the
@.I foreground
or
@.I background.
The distinction is a background process is usually forced to stop when
it attempts to perform I/O (including most control operations) on its
controlling terminal, while a foreground process is not hindered.
@.PP
Specifically, when a background process attempts to read from its controlling
terminal it is sent the SIGTTIN signal which, by default, causes it to stop.
When it attempts to write to its controlling terminal and LTOSTOP has been
enabled for the terminal, then the process is sent the SIGTTOU signal which,
by default, causes it to stop.
If, however, a background process has chosen to catch the signal, the
specified user handler is invoked.
If the process is ignoring or masking the stop signal(s), then
the terminal I/O request returns an I/O error, EIO.
@.PP
A background process is one whose process group (p_pgrp) is not equal
to the process group of its controlling terminal (t_pgrp) (and t_pgrp
is not zero).  All other processes (including ones doing I/O to terminals
that are not their controlling terminals) are considered to be in the
foreground.
@.NH 3
Tty Driver Provisions
@.PP
To distinguish between foreground and background
programs the tty driver must perform checks on attempted I/O operations to
a process's controlling terminal.
This is done in several places.
@.PP
At the beginning of a read/write system call the tty driver checks
to see if the calling process is in the background.
If it is, then all processes in the
process group of the calling process are sent the appropriate
signal (SIGTTIN or SIGTTOU) unless the signal is masked or ignored
by the calling process.  In this case the driver returns the EIO error.
After the tty driver sends the signal, the calling process is put to
sleep waiting for the \fIlightning bolt event\fP\(dg.
@.FS
\(dg The lightning bolt event is a standard
@.UX
event which occurs frequently, for example, every second.
@.FE
This allows the calling process to receive the signal (and usually stop).
When the process returns from the sleep (usually by being continued) the
tty driver repeats the foreground/background check before proceeding with
the operation.
@.PP
When the process is in the foreground, the I/O operation proceeds.
In the case of a terminal read this usually results in the process being
put to sleep to wait for input characters to arrive.
At this point the user could type their suspend character (e.g., ^Z).
This causes the interrupt portion of the tty driver to send SIGTSTP
to the controlling terminal's process group (i.e., all processes which
are in the foreground).  In our scenario this
would include the process sleeping on terminal input, and this would
typically cause it to stop.
@.PP
When a sleeping process is stopped it is also left sleeping as well.
If, in this case, tty input characters subsequently arrived then the
process would
be awakened.  However, because it is also stopped, it would not be
set running; it would merely be "unslept".
@.PP
At some later time the process would be continued (e.g., via a csh
"fg" or "bg" command which sends SIGCONT).
If the process had not been previously unslept it would merely continue
its sleeping; it would receive no indication that it had stopped and
continued.
If the process had been previously unslept it would now be set running.
@.PP
When the process is set running it resumes execution in the tty driver.
Because a (potentially substantial) amount of time has elapsed and
because the process may have been stopped and restarted,
the tty driver is no longer sure whether this process is still in
the foreground.
So before checking if input characters are available, the tty driver
rechecks whether the process is in the foreground or background.
This is necessary because, in our
scenario, the stopped process could have been continued in the background
(via csh "bg").  To check this the tty driver merely repeats the
foreground/background check it made at the beginning of the system call.
@.sp 1
@.NH
SYSTEM V INCOMPATIBILITIES AND THEIR RESOLUTIONS
@.PP
Job control as implemented in 4.2BSD is incompatible with System V
semantics in some significant respects.  This section discusses
each of these incompatibilities and the resolution implemented in HP-UX
to maintain System V compatibility.
@.PP
The system interface needed to support 4.2BSD-style job control,
tailored for System V compatibility as discussed in this section,
is presented in the form of manual page excerpts in [Len86].
@.NH 2
Setpgrp(2) Changes
@.PP
Because the needed semantics of 4.2BSD setpgrp(2) conflict with the
semantics of System V setpgrp(2), the 4.2BSD setpgrp(2) function was renamed
to be setpgrp2(2).  (The choice of new name is arbitrary; setpgrp2 was chosen
in the same spirit as 4.2BSD's wait3(2).)
@.NH 2
SIGHUP Changes
@.PP
System V semantics state that when a process group leader dies, all processes
in the same process group are sent the SIGHUP signal which, by default, kills
all the processes.
@.PP
Job control shells execute a command by making all processes in the pipeline
belong to the same (brand new) process group and by making the first program
in the pipeline be the process group leader.  Typically, the first program in a
pipeline terminates before the other programs.  Under System V semantics,
this would cause the premature death of the remaining pipeline.  Because
of this, 4.2BSD does not generate SIGHUP on process group leader death.
@.PP
In order to support System V semantics and still allow job control to
function properly, HP-UX makes a distinction between a "System V process
group leader" and a "job control process group leader".  A System V
process group leader is given System V semantics (SIGHUP is generated)
and a job control process group leader is given 4.2BSD semantics (SIGHUP
is not generated).
A process which becomes a process group leader via setpgrp(2) is considered
to be a System V process group leader.
A process which becomes a process group leader via setpgrp2(2) is considered
to be a job control process group leader.
Since the HP-UX (and System V) init(1M) program calls setpgrp(2) on behalf
of all processes it spawns, all login shells start out as System V process
group leaders.  A process must explicitly call setpgrp2(2) to deviate from
the System V semantics.
@.NH 2
SIGCLD Changes
@.PP
Under System V, SIGCLD is sent to a process whenever one of its immediate
child processes dies.
Under 4.2BSD, SIGCLD (or its variant, SIGCHLD) is also generated
when a process changes state from running to stopped.
Since a System V application would not expect to receive SIGCLD
under these new circumstances and since a job control shell would
not be able to function properly without such notification, a compatible
compromise was developed.
@.PP
The (parent) process wishing to trap SIGCLD may set a flag when calling
the HP-UX sigvector(2)\(dg
@.FS
\(dg Sigvector(2) is an HP-UX extension proposed to the IEEE P1003 [Head85]
which supports both the reliable
signal operations of 4.2BSD sigvec(2) and the conventional signal
operations of System V signal(2).  In HP-UX, signal(2) is implemented
as a library using sigvector(2).
Note that the changes proposed here to sigvector(2) can be identically
made to 4.2BSD sigvec(2).
@.FE
\|routine to establish a signal handler.  This flag
will cause SIGCLD to be sent for stopped children, in addition to terminated
children.
A System V application using signal(2) will see the System V compatible
SIGCLD semantics.
@.NH 2
Controlling Terminal Changes
@.PP
Under System V, whenever a process group leader dies, the controlling terminal
associated with that process group (if any) is deallocated (disassociated from
that process group).
4.2BSD does not deallocate controlling terminals on process group leader death
for the following reason:
Job control shells make the lead process in every pipeline a process
group leader.  If the controlling terminal for each pipeline were deallocated
whenever the lead process terminated, then the remaining processes would
effectively become background processes (assuming they were currently in
the foreground) and would stop when any of them attempted subsequent I/O to the
terminal.
@.PP
To allow both semantics, controlling terminals are only deallocated when
a "System V process group leader" dies and not when a "job control process
group leader" dies.  (See the discussion of SIGHUP changes above.)
@.PP
However, this change leads to the following problem:
In order for a terminal to be allocated as a controlling terminal for a
new login, it must be deallocated when the previous login terminates.
System V relies on process group leader death to deallocate controlling
terminals (since all login shells are forced to be process group leaders
by init(1M)).
This is no longer reliable since login shells could become "job control
process group leaders".  Further, not all logins are spawned directly
by init(1M); the 4.2BSD rlogin facility is a prime example.
4.2BSD solves this problem by allowing a new login to join the process
group of the controlling terminal which is still allocated from the
previous login.  However this violates System V compatibility.
@.PP
The solution chosen was to mark a process that causes a controlling
terminal to be allocated and to deallocate the controlling terminal
whenever that process terminates.  This reliably catches logins which
are spawned either directly or indirectly from init(1M), whether they are
"System V process group leaders" or not.  Controlling terminals continue
to be deallocated on death of System V process group leaders using the
System V semantics.
@.NH 2
Security
@.PP
Several security holes exist in the 4.2BSD process group altering
mechanisms.  To plug these holes the following changes were made.
@.PP
4.2BSD setpgrp(2) allows a process to alter the process group associated
with another process to any value.
4.2BSD restricts this operation so that the
affected process must pass the same security restrictions enforced when
sending signals, or must be a descendent of the calling process.
However, this still allows a process to join a process group
already associated with another user.
To tighten this security, setpgrp2(2) was further restricted such that if the
specified new process group value is equal to the process ID (pid) or
process group ID of any existing processes, then all such processes must
pass the above security restrictions.
@.PP
Similarly, the 4.2BSD TIOCSPGRP ioctl(2) allows a terminal's process group
to be altered to any value.  This allows a user's terminal to easily become
an additional "controlling terminal" for another user's process group;
keyboard signals can be sent to the other user's processes, thus bypassing
the security enforced by kill(2).
Because of this, the TIOCSPGRP ioctl(2) was altered to enforce similar
security restrictions as setpgrp2(2).
@.PP
In System V and 4.2BSD, a process can obtain access to its controlling
terminal by opening the file \fI/dev/tty\fP.  Under System V, processes
left executing after a user's logout are allowed further access to
\fI/dev/tty\fP until the terminal it represents is reallocated as a
controlling terminal for a new login.  More specifically, \fI/dev/tty\fP
access is allowed whenever the process group ID of the leftover process
matches the process group ID of the terminal.  These IDs continue to match
immediately after logout (since both have been zeroed) until the terminal
is re-enabled for login by getty(1M).  (Note that when the new login
terminates, \fI/dev/tty\fP access is restored again to these prior processes
because the controlling terminal's process group ID is re-zeroed.)  Further,
if a process has its controlling terminal opened directly (not
via the \fI/dev/tty\fP synonym) then access is not restricted at all after
logout.
These System V semantics can constitute security problems.  However, they
are not explicitly required by the System V Interface Definition [ATT86].
@.PP
4.2BSD does nothing to hamper \fI/dev/tty\fP access for processes remaining
after logout.  The process group ID for the controlling terminal is not
altered, and, in fact, it is preserved even into the next login (since
subsequent logins join the already existing process group associated with the
terminal, if any).  These semantics also represent security problems.
However, 4.2BSD does prohibit access to the controlling terminal if it
is opened directly; this is accomplished when init(8) issues the vhangup(2)
system call.
@.PP
Although preserving the System V semantics for controlling terminal access
after logout is not deemed necessary or even recommended, it is easy to do
in the following way.
Whenever a process that allocated a controlling terminal dies, all processes
which share this controlling terminal have their process group ID zeroed.
This is analogous to, and occurs in addition to, the System V behavior of
zeroing the process group ID for all related processes when their process
group leader dies.  \fI/dev/tty\fP checks similar to System V can then
be employed.
@.NH 2
TTY Driver Considerations
@.PP
For System V compatibility, the suspend and delayed suspend characters
are defaulted to a disabled value (0377).  This means that job control
is "inactive" by default when a user logs on.  The user must explicitly
activate job control by defining either or both of these characters via
stty(1) or some similar interface.
@.PP
There should be no problem allowing 4.2BSD-style job control, as modified
here, to co-exist with System V's shell layers job control system.
(See shl(1) and sxt(7) in the System V Release 2 reference manuals.)
@.sp 1
@.NH
HP-UX
@.NH 2
Introduction
@.PP
HP-UX process groups are used in two major ways.
@.PP
System V process groups closely resemble the concept of a login session.
That is, all processes spawned during the same login session tend to
belong to the same process group, and keyboard signals are typically
sent to all processes spawned from the login session.
@.PP
Job control process groups closely resemble the concept of a task within
a login session, where a task represents a set of processes which
are affected as a group by job control operations.
Every time a job control shell (e.g., csh) spawns either a foreground
or background command, all processes in the pipeline (and their
descendents) are placed in their own unique process group with the
first command in the pipeline being the process group leader.
@.PP
A task is in the foreground when the process group associated with the
controlling terminal for the task (t_pgrp) is equal to the process
group associated with the processes in the task (p_pgrp).
Otherwise the task is in the background.
A job control shell moves a job between the foreground and background
by adjusting the terminal process group (t_pgrp) of the controlling
terminal.
@.PP
Note that a job control shell forms new process groups with process
group leaders
much more often than a non-job control (System V) shell usually does
(every command versus every login).
@.NH 2
HP-UX Process Group Handling
@.PP
In HP-UX, the process group associated with a process (p_pgrp)
can be altered via setpgrp(2) or setpgrp2(2).
@.PP
As in System V, setpgrp(2) can only set the process
group to equal the process ID (pid) of the process.  When this happens,
the resulting process with pid = p_pgrp is called a System V process group
leader.
@.PP
Setpgrp2(2) is analogous to setpgrp(2) except that it can affect
processes other than the current process and can cause the affected
process to adopt a process group other than that process's process ID (pid).
Setpgrp2(2) also forms job control process groups rather than System V
process groups.
Using setpgrp2(2), the calling process, or certain other processes, can either
become a job control process group leader or can cease to be a process
group leader.
@.PP
Because job control process groups are handled slightly differently
by HP-UX than System V process groups, HP-UX marks processes
that are job control process group leaders (i.e., that have
called setpgrp2(2) without subsequently calling setpgrp(2)).
@.PP
The init(1M) process spawns all other processes on the system either
directly or indirectly.  Before directly spawning a process
(after the fork(2) but before the exec(2)),
init calls setpgrp(2).
Thus all original children (not orphans) of init are forced to
start out as System V process group leaders.
@.PP
When a new process is created, it is assigned a new pid but it inherits
the process group number of its parent.  Thus child processes are, by
default, not process group leaders (although they can become a process
group leader via either setpgrp(2) or setpgrp2(2)).
@.PP
When a System V process group leader that has a controlling terminal
(see below) terminates, SIGHUP is sent to all processes in the same
process group.
Further, when a System V process group leader terminates, all processes
which belong to this process group are altered to belong to no process group
(their p_pgrp is set to zero).
@.PP
Also, whenever any process that allocated a controlling terminal terminates,
all processes that share this controlling terminal are altered to belong
to no process group (their p_pgrp is set to zero).
@.PP
When any process exits, any pending SIGTTIN, SIGTTOU, and SIGTSTP signals
are cleared from all descendent processes (not just immediate children).
@.NH 2
HP-UX Controlling Terminals
@.PP
A terminal that is currently open by a process may also be a "controlling
terminal" for a process group (collection of processes).  When certain
control characters are typed on a controlling terminal, signals are
sent by the terminal driver to all processes which belong to the process
group associated with the terminal.  These include the job control suspend
and delayed suspend characters.
@.PP
Controlling terminals also play a role in determining whether a process
is in the foreground or background.  See FOREGROUND/BACKGROUND PROCESSES
above.
@.PP
When a process becomes a System V process group leader (via setpgrp(2)) it
automatically loses its controlling terminal.
(This does not happen for a job control process group leader, i.e. when
calling setpgrp2(2).)
After this,
the first terminal (that is not already a controlling terminal)
opened by a process that is a (System V or job control) process group leader
is assigned to be the controlling terminal for that process;
also the process group associated with that terminal (t_pgrp) is set
equal to the process group associated with the process group leader
process (p_pgrp).
All child processes inherit the controlling terminal and
process group of their parent.
@.PP
More precisely, in HP-UX, the process group associated with a
terminal (t_pgrp), can be changed in the following ways:
@.IP (1)
When a terminal is opened by a System V or job control
process group leader (pid == p_pgrp)
that does not already have a controlling terminal,
it becomes the controlling terminal for that process group
(t_pgrp is set equal to p_pgrp) if it is not already a controlling
terminal.
@.IP (2)
When a System V process group leader (pid == p_pgrp) dies, if it has a
controlling terminal that is associated with the same process
group (t_pgrp == p_pgrp), that terminal is disassociated from that
process group (t_pgrp is set to zero).
@.IP (3)
When any process dies which originally caused a controlling terminal
to be created (see (1) above),
if it still has a controlling terminal,
that terminal is disassociated from its
process group (t_pgrp is set to zero).
@.IP (4)
When the last process to have a terminal open closes that terminal,
the terminal is disassociated from its process group (t_pgrp
is set to zero).
@.IP (5)
The TIOCSPGRP ioctl(2) call can explicitly change a terminal's
process group (t_pgrp) to any value within certain security restrictions.
This is used by a job control shell to change which set of processes
(process group) is in the foreground.
@.NH 2
HP-UX Typical Scenario
@.PP
This is a typical scenario for the birth and death of a login, its
controlling terminal, and the process groups associated with a job.
@.PP
The init(1M) process wants to enable a terminal for login.  It creates a
new process via fork(2) and calls setpgrp(2) to make it a System V process
group leader which also removes its controlling terminal.  Init then runs
the getty(1M) program as the process via exec(2).
Getty opens the terminal causing the terminal to become getty's controlling
terminal
and be associated with getty's process group (t_pgrp is set to p_pgrp).
As a side effect, this process is now marked as having created a controlling
terminal; when it dies the controlling terminal will be freed for re-use.
Getty replaces itself with login(1) which replaces itself with a login
shell.
@.PP
At this point one of two scenarios typically takes place.  The login shell
is either a job control shell (e.g., csh(1)) or it is not (e.g., sh(1)).
@.PP
If the login shell is not a job control shell then things proceed much
as they do on System V.
Usually no program calls setpgrp(2) or setpgrp2(2) and thus all
descendent processes
of the login shell are in the same process group and have the same
controlling terminal; keyboard signals are sent to all processes launched
during this session.
@.PP
If the login shell is a job control shell, then job control operations are
performed.
Csh begins to manipulate the process group associated with the
terminal (t_pgrp) via the TIOCSPGRP and TIOCGPGRP ioctl(2) calls and
the process group associated with its child processes (p_pgrp) via
setpgrp2(2) in order to allow job control.  This happens (briefly) in the
following way:
@.PP
Csh launches a pipeline by making all programs in the pipeline be
immediate descendents of csh.  (This is different from sh which makes
all programs in the pipeline except the last be descendents of the
last program in the pipeline.)
All programs in the pipeline belong to the same process group (not the
same as csh's process group) and the first program in the pipeline is
the process group leader (its pid is equal to the process group for the
pipeline).  This process is specially marked as a job control process
group leader since it was established via setpgrp2(2); this basically
prevents SIGHUP from being sent to the pipeline when the lead process dies.
If the pipeline is being launched in the foreground (or moved to the
foreground) then the process group associated with the terminal (t_pgrp)
is set to the process group of the pipeline via the TIOCSPGRP ioctl(2).
@.PP
When a logout occurs, the login shell dies.
Any pending SIGTTIN, SIGTTOU, and SIGTSTP signals are cleared for all
descendent processes.
All immediate child processes are inherited as orphans by init; if any are
currently stopped then they are killed (SIGKILL).
Since the login shell (actually the getty before it was overlaid) created
a controlling terminal, the controlling terminal is now freed (t_pgrp
is set to zero) so that it can be claimed as a controlling terminal by
a subsequent getty respawned by init; also, all processes which share
this controlling terminal have their process group (p_pgrp) set to zero.
@.PP
When a logout occurs and
the login shell is a System V process group leader, SIGHUP is sent
to all processes in the same process group, and the process group (p_pgrp)
of all descendent processes is set to zero.
@.PP
Note that there may continue to be background processes (previously
started by the
now defunct login shell) which continue to execute but
keyboard signals will no longer be sent to these processes (since
both t_pgrp and p_pgrp equal zero).
@.sp 1
@.NH
ACKNOWLEDGEMENTS
@.PP
The following people from Hewlett-Packard contributed to the interface
design and implementation of job control for HP-UX:
Jim Barton,
Dave Decot,
Larry Dwyer,
Jeff Glasson,
Rita Hanson,
Stephen Hares,
Steve Head,
Bob Lenk,
John Marvin,
Dave Mears,
Peter Notess,
Arn Schaeffer,
Eviatar Shafrir.
@.PP
Guy Harris from Sun Microsystems made many substantive comments and suggestions
which contributed to the interface design and to this paper.
@.sp 3
@.NH
REFERENCES
@.IP [ATT86] 15
\fISystem V Interface Definition\fP, Issue 2, AT&T, 1986.
@.IP [Bach84]
M. J. Bach and S. J. Buroff, "Multiprocessor
@.UX
Operating Systems",
\fIAT&T Bell Lab. Tech. J.\fP, \fB63,\fP No. 8 (October 1984),
pp. 1733-1749.
@.IP [Head85]
Stephen Head and Donn Terry, "Reliable Signals Proposal",
IEEE P1003 Proposal #P.042, Hewlett-Packard Co., September 11, 1985.
@.IP [Joy80]
William Joy, "An Introduction to the C Shell",
Computer Science Division, University of California
at Berkeley, November 1980.
@.IP [Len86]
David Lennert, Guy Harris, et. al.,
"System V Compatible BSD-style Job Control Facilities",
IEEE P1003 Proposal #P.047, Hewlett-Packard Co. & Sun Microsystems,
April 9, 1986.
@.IP [Ritch79]
Dennis M. Ritchie, "The
@.UX
I/O System",
\fIUNIX Programmer's Manual\fP, Seventh Edition, Volume 2b,
Bell Telephone Laboratories, Murray Hill, NJ, January 1979.
@.IP [Roch85]
Marc J. Rochkind,
\fIAdvanced
@.UX
Programming\fP,
Englewood Cliffs, N.J.: Prentice-Hall, 1985.
@.IP [Harris86]
Guy Harris, "Notes on Signal, Terminal Interface, and User/Group ID
Handling Proposals", IEEE P1003 Proposal #P.045, Sun Microsystems,
January 11, 1986.
@.IP [Thom78]
K. Thompson, "UNIX Implementation",
\fIBell System Tech. J.\fP, \fB57,\fP No. 6 (July - August 1978),
pp. 1931-1946.
@.IP [UCB83]
\fIUNIX Programmer's Manual\fP, 4.2 Berkeley Software Distribution, Virtual
VAX-11 Version, Computer Science Division, University of California
at Berkeley, August 1983.
@.PP
@.bp
@.DS C
APPENDIX

JOB CONTROL MANUAL PAGE EXCERPTS
@.DE
@.PP
The following pages contain the
@.UX
manual pages which are effected by adding a System V compatible
implementation of 4.2BSD job control.  Note that each manual page
generally contains only that portion of text which differs from the
System V manual page of the same name.  Sometimes, unchanged text
is provided for locality reference.  Changed text lines are flagged
with change bars.
@//E*O*F jobpaper.ms//
chmod u=rw,g=rw,o=r jobpaper.ms

echo Inspecting for damage in transit...
temp=/tmp/shar$$; dtemp=/tmp/.shar$$
trap "rm -f $temp $dtemp; exit" 0 1 2 3 15
cat > $temp <<\!!!
   1200   8792  53685 jobpaper.ms
!!!
wc  jobpaper.ms | sed 's=[^ ]*/==' | diff -b $temp - >$dtemp
if [ -s $dtemp ]
then echo "Ouch [diff of wc output]:" ; cat $dtemp
else echo "No problems found."
fi
exit 0


Volume-Number: Volume 7, Number 54

From news  Tue Oct 14 11:13:01 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 14 Oct 86 16:12:48 GMT
Draft-9: job.control

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Sun, 12 Oct 86 23:50:46 edt
Organization: AT&T Medical Information Systems, Columbus

The virtual screen stuff, such as UNIX or Xenix on a PC have, should be
considered a poor cousin of a true bitmapped window capability.  Aside
from losing the ability to watch two windows at once, they are essentially
the same.  Both are nice, neither is an alternative for anything except
a personal computer or workstation.

By the way, another possibility has been suggested: something like System
V's shell layers, but using scrolling regions in a vt100 or similar terminal
to lock the terminal into the appropriate window.  You lose the ability to
see async updates in another window, and you still need ptys and select,
but you don't need curses, and you shouldn't get the mushy feeling.
Something would have to be done about ^Z not working in raw mode, so you
could break out of an rlogin or cu or vi.  One way to do this would be
something like Berkeley's TIOCSTI, so the program can detect the situation
(using a multi-char escape sequence), take itself out of raw mode, and
type the ^Z itself.

(Henry's complaint about user programs having to be modified is a minor
one, in my opinion.  A program that isn't screen oriented needs no
modification.  A program that is screen oriented can use curses, and
curses can catch the signal and redraw the screen as needed.  The only
programs that need modification are those that have to be transparently
able to pass ^Z through, this mostly means remote login programs, and
they need this kind of capability without job control anyway.)

>From: [e-mail] (Guy Harris)
>
>> (1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
>> acts like a terminal.  This is unquestionably the best, but it
>> requires special hardware, and is an area that needs to be
>> standardized.
>
>At some point, perhaps.  It's unclear whether now is the time to do so.

I did not mean to imply that it should be standardized NOW, although I
think the field is starting to generate enough examples that it would be
worthwhile for someone to start looking at it.  We certainly aren't ready
to put it into P.1003 yet.

What I meant is that certain common elements should be standardized,
in particular, the ioctl to get and set the current window size.
These all look the same, but with different particulars.

>> (b) an ioctl to find out the current window size, in chars and pixels.
>
>The current proposal has this, but does not give the window size in pixels.
>The "termio" interface is really not a good portable interface for doing
>graphics, since most terminals can't do graphics.  As such, it's not clear
>why the window size in pixels should be provided by this interface.

The reason I mention pixels is that many of the existing ioctls seem to
bundle the pixel numbers and char numbers into the same ioctl.  Perhaps
it does make sense to separate them.

By the way, I think both "get" and "set" operations should be standardized,
and the standard should state that both ioctls must work on both sides of
the pty.  (This assumes we can appropriately specify what a "pty" is.)

The "get" operation can indeed be isolated into tgetnum (termcap) and
setupterm (terminfo.)  But lack of standardization means that the sources
to termcap and terminfo have to be cluttered up with umpteen different
ways to do the same thing.

The "set" operation is needed for window managers, and also so there can
be a shell command to set the window size when the system gets it wrong.
(The system gets it wrong a lot in practice, all you have to do is remote
login through a link that doesn't pass the window size, such as cu, telnet,
or 4.2's rlogin.  (4.3 passes the size.))  Sometimes windows get resized,
too, so it would be useful for the cu/rlogin program to be able to send a
shell command through when this happens.)

    Mark

Volume-Number: Volume 7, Number 55

From news  Tue Oct 14 11:28:26 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 14 Oct 86 16:28:12 GMT
Draft-9: 2.3.folding

From: mcvax!axis!philip (Philip Peake)
Organization: Axis Digital, 135 rue d'Aguesseau, Boulogne, 92100, FRANCE

>OK, here's a new topic.  File names.
>
>UNIX is the only major operating system
>that treats things like file names, logins, host names, and commands
>as case sensitive.  The net effect of this is that users get
>confused, since they have to get the capitalization right every time.

This is mainly because such users move from restrictive environments
where they are forced to use a single case. if you look at the problems
of *NEW* users - those not having been crippled by having already worked
in a single case environment, the natural method of working is in
two cases. I have never found anyone incapable of understanding that
upper and lowwer case letters are different.

>To avoid confusion, everybody always just uses lower case.

Maybe you do, but, there are many people who don't.

>there are few, if any, benefits from a two-case system, and any time
>anyone tries to do something that isn't pure lower case, it causes
>confusion for somebody and often breaks some program.

This is mainly bad software engineering. Taken to its logical conclusion
one could say that letting users get at programs often breaks them
(the programs that it, (usually)) so let's ban users.

>Another problem is that emulations on other operating systems,
>such as VMS or MS DOS, will become impossible without drastic
>changes to their file systems.  Given the problems in the above
>paragraph, plus politics as usual, I think it is unlikely that
>other systems will be changed to have case sensitive file systems.
>After all, it's not like it was easiest to make the VMS filesystem
>case insensitive - that took extra effort on their part.

It seems to me that this extra effort was needed to circumvent the
extra effort needed in making their system work correctly with
all the legal ascii characters - it was designed by a team of
people who had been mentaly crippled by using such a one-case
system.

>I think it's a mistake to move in the direction of requiring other
>operating systems to become case sensitive.  If anything, motion in
>the other direction might be of more benefit.

This seems like a retrograde step.

>Note: I am NOT suggesting that UNIX should have a case insensitive
>filesystem that maps everything to UPPER CASE like MS DOS.  There is
>nothing wrong with mapping everything to lower case, for example.
>It's also reasonable to leave the case alone, but ignore case in
>comparisons.  There is also probably a good argument for keeping
>it case sensitive (after all, there are probably 5 or 6 people out
>there who really need both makefile and Makefile, or both mail and
>Mail, for some reason that escapes me at the moment.)

Here we have a typing error, I think that you really meant 5*10^4 or
6*10^4, didn't you Mark ?

This seems to be a logical extention to the ridiculous proposal
for command names and options which came from Bell Labs. some time
ago - all lower case, single letter options etc.

If you want to use upper and lowwer case for login names, it is a simple
matter to re-write login to be case insensitive.

If you want the same for file name handling in the shell, again it is
fairly simple to add a test for some environment variable, which
would force upper-lower case equivalence. Exactly what happens then
if you have both Makefile and makefile (which is another case of bad
software enginering - that make accepts both) you get both files,
or maybe an error. That's your problem, but I want to keep the ability
to use both cases.

In a more general case, are you suggesting that UNIX is going to be
forever tied to ASCII - what about internationalisation issues - how
do you handle non-english alphabets where case may be CRITICALLY
important.

I would propose that the current scheme is a good one - allow file names
to be composed of any characters in the base character set.

Philip Peake

Volume-Number: Volume 7, Number 56

From news  Tue Oct 14 11:43:08 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 14 Oct 86 16:42:39 GMT
Draft-9: job.control

From: [e-mail] (Bill Shannon)
Date: Sun, 12 Oct 86 22:37:40 PDT

> From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
>
>    ...
>
> (b) an ioctl to find out the current window size, in chars and pixels.

I've argued this with the people at Berkeley and lost, but I'll try
again here.  I don't believe there should be an ioctl to find out
the pixel size of a "window".  This seems to me to be the wrong way
to retrieve this information.  The pixel size is of no use to programs
that deal only in characters.  Only programs manipulating windows will
need to know the pixel size.  Whatever mechanism is used to manipulate
window should also be used to find out the pixel size of the window.
(Of course, this may be, but is not required to be, ioctl's.)  The tty
subsystem, which deals only in characters, should not know anything
about pixels or windows.

                    Bill Shannon

Volume-Number: Volume 7, Number 57

From news  Tue Oct 14 11:45:25 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Keywords: windows virtual consoles termcap terminfo
Date: 14 Oct 86 16:44:57 GMT
Draft-9: job.control

From: [e-mail] (Larry Campbell)
Date: Sun, 12 Oct 86 11:43:38 EDT
Organization: The Boston Software Works, Inc.

In article <[e-mail]> [e-mail] (Guy Harris) writes:

>This sort of windowing mechanism doesn't even necessarily require a
>memory-mapped screen; it merely needs a way to redraw a window when it moves
>to the front.  Mark Horton's earlier message describes a window manager for
>dumb terminals; it even permits more than one window on the screen.

Of course, but I suspect that redrawing windows over a serial line
would be tedious -- unless the serial line were running at 56KB or better.

>As for the window size "ioctl", consider this: any program that thinks it's
>always dealing with a "perfectly ordinary 24x80 terminal" is going to be
>quite surprised when run on an Ann Arbor Ambassador with 60 lines.  Programs
>should not make assumptions like that.

That was an oversimplification on my part.  Of course programs should
(and most do) query termcap/terminfo.  However, they can safely assume
that the window size isn't going to change while they're running, and
this assumption reduces complexity.
--
Larry Campbell            MCI: LCAMPBELL   The Boston Software Works, Inc.
ARPA: [e-mail]   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     [phone]

Volume-Number: Volume 7, Number 58

From news  Tue Oct 14 13:59:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 14 Oct 86 18:59:09 GMT
Draft-9: Access.Standards

From: pyramid!amdahl!amdcad!qubix!wjvax!brett (Brett Galloway)
Date: Mon, 13 Oct 86 09:39:13 pdt
Organization: Watkins-Johnson Co., San Jose, Calif.

In article <[e-mail]> Hal Jespersen writes:
>
>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
>...
>    programmatic interfaces to the shell (system(), popen()) and
>    related facilities (regular expressions, file name expansion,
>    etc.)
>...

I think that it would be great to standardize the command set available -- this
would make writing makefiles and command servers (shell escapes) under other
applications much more portable.  One feature that I would like to see is an
alternative interface to system().  System() is great unless the user is doing
his own child process management.  In that case, he would like to do the fork()
and exec() himself and not let system() do it for him.  The alternative
interface should be some new variant of exec() (like execvp()) which sets up
the call to the appropriate command processor.

-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett

Volume-Number: Volume 7, Number 59

From news  Wed Oct 15 11:15:09 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: case sensitive names
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 15 Oct 86 16:14:52 GMT
Draft-9: 2.3.folding

From: [e-mail] (Barry Shein)
Date: Sun, 12 Oct 86 14:02:11 EDT

Other operating systems use case insensitivity in their file names, why?

    As I remember it is a holdover of older encoding conventions
    intended to save disk space. PDP-10s used SIXBIT, RT11 and
    others used RAD50, in the real old days people used 026's and
    ttys, all of these had only one case for A..Z. I don't think
    it was a human factor, it was an economy of a different age.
    Systems like VMS and CMS continue this due to their heritage.

At least make user names monocase.

    Is the convention that upper-case user names imply an
    upper-case only terminal being discarded? If not, what
    is the new convention? What else should we redesign?

At least make file names monocase (a)

    Please list all software this would affect, besides Make.
    How many mktemp() calls make use of case? Lock files?
    Are you *sure* none of these would be affected adversely?

...it would make emulators easier (b)

    As has been noted EUNICE doesn't seem to have too much
    trouble with exactly this. Any comments/requests from
    EUNICE developers? HCR? Why are we protecting them if they
    don't ask for this? My guess is they wouldn't consider it
    critical and would cause them as many problems as it would
    solve (they would have to now go and "fix" their software also.)

At least make flags monocase.

    Please list all current flags which rely upon case sensitivity
    and what you would replace them with. Worse, we have lost the
    thread of this proposal. Is the case fixed in filenames when the
    kernel interprets them? By the shell? Does the shell now have
    knowledge about what is a flag? If not, how *do* I pass a data
    string (such as sed s/foo/goo) in mixed-case where needed? This
    is often a can of worms in other os's (eg. VMS/DCL) and not what
    I would call an improvement. It might require detailed syntactic
    and semantic knowledge of command formats by the shell(s) as most
    of these monocase systems have (DCL, EXEC etc.) At best it would
    require various new or further overloaded quoting conventions
    (we now have quote, double quote, backslash, ^V and backquote!)

It would be more ergonomic.

    Why is having less obviously easier? I thought the freedom
    UNIX gives in creating things like file names to suit whims
    to be a plus. Should we adopt NAME.EXT conventions? Why not?
    Doesn't the structure imposed by .EXT make things "easier" in
    the same sense? What about very long file names? Is this also
    a "pain"? Why have so many of the proponents argued about how
    all this would make it easier ON THE PROGRAMMER? (eg. emulator
    writers, argv interpreters) Is this the person the system's
    interface should be optimized for? What about text processors
    (I mean people)? Do they use the filing system in full case
    or not? Do we care? I just scanned through our dept secty's
    directories (she is a very naive user, she started here with
    UNIX this summer, it also includes a subdir which is the entire
    tree of her predecessor who was a fairly sophisticated UNIX user.)
    It is full of mixed case filenames, most for the obvious reasons
    (PhoneBill, LICENSES (probably to force sorting to the beginning),
    etc.)

    Would you please peruse *your* user's directories and report back?

Where does it stop?

    What about things like 'r' and 'R' in mail(x)? You may know
    the difference between a shell and an application program,
    but do your users have it as clear or will they see these
    things as gross inconsistencies if not brought into line?
    What about editors ('q' vs 'Q') and other fundamental software?
    Who enforces this (the application or the tty driver)?

The proposal to remove case sensitivity does not analyze the impact on
the software and the amount of change needed to accomodate this new
feature. I claim it is ubiquitous, worse, the proposal is ill-defined
as to exactly where in the software hierarchy this case insensitivity
is to be implemented. The proposal is pie-in-the-sky and unworkable,
worse, it is regressive (eg. it actually strives to emulate systems
designed to be compatible where now outmoded hardware and economies
were driving forces.)

Take your UNIX system, change everything to lower case. Add the following
line to your .login or .profile:

    stty lcase

report back to us if you still think this is a good idea.

    -Barry Shein, Boston University

Volume-Number: Volume 7, Number 60

From news  Wed Oct 15 14:24:39 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 15 Oct 86 19:24:17 GMT
Draft-9: job.control

From: [e-mail] (Guy Harris)
Date: Wed, 15 Oct 86 11:18:03 PDT

> What I meant is that certain common elements should be standardized,
> in particular, the ioctl to get and set the current window size.
> These all look the same, but with different particulars.

This isn't really just a window system issue; the current "termios" proposal
avoids referring to it as a "window" size.  One could imagine features, such
as end-of-"page" pauses in the TTY driver, that would use this information
even on dumb terminals.

> By the way, I think both "get" and "set" operations should be standardized,
> and the standard should state that both ioctls must work on both sides of
> the pty.  (This assumes we can appropriately specify what a "pty" is.)

The "set" operation is in the "termios" proposal; since "pty"s aren't, it
doesn't say anything about whether the operation works on both sides or not.

Volume-Number: Volume 7, Number 61

From news  Thu Oct 16 10:48:02 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 16 Oct 86 15:47:50 GMT
Draft-9: 2.3.folding

[ *sigh*  Below you will find two examples of proof by emotion,
one for case sensitivity, one for case insensitivity.  Now that
we have one on each side together like this, how about let's
either use facts and arguments or go on to another subject?

Below the second example there is a somewhat new point, marked
by another interjection from the moderator.  -mod ]

From: seismo!mcvax!gec-mi-at.co.uk!adam
Date: Thu, 16 Oct 86 09:29:20 -0100
Organization: Marconi Instruments Ltd., St. Albans, Herts, UK

>I would like to add a loud "Bravo!" to Mark Horton's message!  The present
>case sensitivity of the Unix filesystem is a real drag....

No NO nO NO nO No no! Case sensitivity is a bonus. If you can't handle it,
it's your problem. I've worked with both case-sensitive, -preserving and
-insensitive systems, and I prefer them in that order.

       -Adam.

From: pyramid!lll-crg!nike!ucbcad!ucbvax!excelan!donp (Don Provan)
Date: Wed, 15 Oct 86 09:58:48 pdt

This is a good example of why people coming from other operating
systems so often dislike UNIX.  Two people pointed out what is
clearly a bug in UNIX which particularly upsets them.  Many people
responded that it was a feature.  Hrumph!

[ Below is the new point.  -mod ]

If you're so concerned about correctly handling of foreign languages,
why don't you start by handling English correctly?  In English,
"Make" and "make" are considered identical.  Capitalization rarely
has an effect on meaning.  Yet in UNIX, "Makefile" and "makefile" are
two different files with different "meanings".  Where are your *NEW*
users that are going to understand this sudden departure from a rule
of their native tongue?

[ The point is wrong.  Capitalization is significant in English:
internet and Internet do not have the same meaning, nor do john and
John (for readers outside the States, perhaps I should point out that
john with no capital refers to a toilet).  The distinction applies
not only to proper names but also in Emphasis and in syntax at the
beginning of sentences.  -mod ]

I am not sufficiently versed in foreign languages to understand the
issues concerning capitalization there.  It sounds like in some cases
the rules of what letters are equivalent (such as "A" and "a" in
English) might require tailoring.  If you're going to support foreign
languages in a meaningful way, i assume you're going to make lots of
other modifications, too.  For example, "Makefile" would need to have
a different name, right?  (I suppose the UNIX utilities themselves
already have names far enough removed from English so that they're no
problem.  What *does* "ls" stand for, anyway?)

[ As a moderately good reader of French and Spanish, I believe I can
state that the same sort of capitalization conventions exist in them as
in English, but with different details as to when capitalizaition is
appropriate.  The lexical details also differ:  the capital of ll (a single
letter in Spanish) is usually Ll, except when it's LL; in French, whether
an e with an acute accent still has an accent in its capital E form
depends on whether you're in France, Belgium, Quebec, Louisiana, etc.

I understand Greek is an interesting language:  there are several kinds
of lower case forms of some letters, to be used in different places in
a word (beginning, middle, end).  Similar distinctions exist in Arabic.

And, as several people have pointed out, case isn't meaningful in
Chinese, Korean, or Japanese kanji.  Also, the number of bytes used to
encode a character changes with the language, and multiple languages
should be supportable on the same system (in Japan, they commonly use
English, Japanese in romanji, and Japanese in Kanji; in Scandinavian
countries I suspect they have a lot of English interspersed with the
national language in technical literature).

In most European countries, UNIX command names are used unchanged,
and Makefile does not in fact have a different name.  Would some
Europeans care to comment?
-mod ]

Having done a lot of case insensitive work, i've always felt that the
UNIX case sensitivity was from laziness.  If i were to be charitable,
i might go so far as to call it a shortcut.

[ See Doug Gwyn's previous article for a good explanation of why file
names are case sensitive (or, rather, byte streams uninterpreted by the
kernel) in UNIX (see Barry Shein's article for a good explanation of why
some other systems are case insensitive).  In places where there was a
reason for case insensitivity (e.g., to match mail standards), it has
been done.  -mod ]

  But it's ridiculous to
say it makes more sense or it makes UNIX easier for new users or it
allows UNIX to support foreign languages.

[ "Ridiculous" is not an argument.  -mod ]

                        don provan

Volume-Number: Volume 7, Number 62

From news  Thu Oct 16 11:09:18 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Unix/World article on POSIX
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 16 Oct 86 16:09:01 GMT
Draft-9: Access.Unix/World

There's an article in the October Unix/World that explains the intent
of P1003 pretty clearly.  It's by the committee chair.  In refer format:

%A Jim Isaak
%T Standards for the Unix System
%J Unix/World
%I Tech Valley Publishing
%C Mountain View, CA
%V 3
%N 10
%P 34-38
%D October 1986

It mentions 1003.1, 1003.2, 1003.3, /usr/group committees, X/OPEN and SVID.

There are also articles on X3J11 and networking standards in the same issue.

Volume-Number: Volume 7, Number 63

From news  Fri Oct 17 10:09:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Oct 86 15:08:45 GMT
Draft-9: job.control

From: [e-mail] (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Date: 15 Oct 86 12:23:31 PDT (Wed)

> From: [e-mail] (Bill Shannon)
> I don't believe there should be an ioctl to find out the pixel size of a
> "window". ...  The pixel size is of no use to programs that deal only in
> characters.  Only programs manipulating windows will need to know the pixel
> size.  ...  The tty subsystem, which deals only in characters, should not
> know anything about pixels or windows.

Naive programs should have access to window size as character information,
but there are programs which do not manipulate windows which need window
size information in pixels.  My solution would be to provide the size in
character units but also provide character cell size in pixels with the same
call (ioctl or whatever).  Programs could use it or ignore it.

Whether the tty system does know about pixels or not, it should.  If the
window size information (in character units) is going to be accurate, window
sizes must be restricted to integrals of character size.  With straight ttys
this is no problem, but if the system supports font changing, character size
can vary.  Rather than require one call to find the window size and then
another call to find out what the units are, this information should be
consolidated into a single place.

Volume-Number: Volume 7, Number 64

From news  Fri Oct 17 10:11:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Oct 86 15:11:29 GMT
Draft-9: job.control

From: [e-mail] (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR

In article <[e-mail]> Larry Campbell
<[e-mail]> writes:
> Of course programs should (and most do) query termcap/terminfo.  However,
> they can safely assume that the window size isn't going to change while
> they're running, and this assumption reduces complexity.

Programs cannot safely assume that window size is not going to change,
because on most overlapped window management systems it will.  It is just
too easy to set inappropriate window sizes and then need to adjust them.
Consider creating a new which is almost the right size (say 75 characters
wide) and then invoking an editor on a file of 80 character data.  The
editor will either wrap or truncate the data, and changing the window size
to compensate will do nothing but frustate the user.  What is needed is
something like 4.3 BSD's WINCH signal, to advise those applications which
care about such changes.
--
Robert Reed, Tektronix CAE Systems Division, [e-mail]

Volume-Number: Volume 7, Number 65

From news  Fri Oct 17 11:28:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: case sensitivity
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Oct 86 16:28:30 GMT
Draft-9: 2.3.folding

From: <@SUMEX-AIM.ARPA:MRC@PANDA> (Mark Crispin)
Date: Thu 16 Oct 86 23:13:06-PDT
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: [phone]

     I was hoping that the moderator would stay neutral in this.
I encourage his subsequent neutrality.

[ The moderator is neutral.  A statement on editorial policy is
forthcoming.  If you want to discuss that issue, let's do it in
that channel and not this.  -mod ]

     It seems that the two sides in this issue boil down to this:
. "gee, since we're defining a standard portable operating system
  that isn't necessarily the present de facto Unix, let's fix
  this case sensitivity cretinism"
. "case sensitivity is what makes Unix better than any other
  operating system, and only a cretin can't understand why this
  is wonderful"

     Neither side is being very scientific.  It's reminiscent of
the "how many angels can dance on the head of a pin" debates.

     Let's start by discarding the arguments which are bogus.
The most glaring of these has got to be the international
compatibility argument.  The only advocates of this argument seem
to be pro case sensitivity Americans who have seized upon this as
an argument to shore up their position without really thinking
over the issue carefully.

[ Perhaps you could elaborate on why X/OPEN (a group of European
computer manufacterors), for instance, should not be concerned
with international compatibility?  -mod ]

     Unix does not allow arbitrary strings in filenames.  Any
number of "funny" characters must be within a quoted string.  I
can't say
    rm foo.bar;1
I have to say
    rm "foo.bar;1"
Guess what.  A number of foreign keyboards use those "funny"
characters to be non-English glyphs.

[ The *shell* interprets certain characters, causing
them to have to be quoted if they are used in file names.
The file system is perfectly happy to put just about anything
but the slash and null characters in filenames.  -mod ]

     I have yet to hear of any organization in Japan using kanzi
or hirogana or katakana in filenames.  There are good reasons for
this!  One is that there isn't a single way of representing
written Japanese.  In older terminals, the high order bit when
set indicated katakana (much as DEC VT220's use the high order
bit for their "international characters").  Modern Japanese
terminals use the JIS (Japanese Industrial Standard) system of
ESCAPE followed by two bytes to define a 14 bit character.
There's a minor portability problem with all those escape
characters (which, of course, must be displayed in image form).

[ Perhaps someone from Japan could reply?  -mod ]

     Some German keyboards use various 7-bit glyphs (I believe
"@" is umlaut-a) for their umlauts and ess-tset.  Or, there's the
VT220 system.  I just tried creating a file called Goethestrasse
(using umlaut-o for "oe" and ess-tset for "ss") on my local Unix
system using my VT220 clone.  It made "GVthestra_e", the 7-bit
form.  Dare I mention that in German, only nouns (and the first
word in a sentence) are capitalized?

[ What is the "it" that made it?  How did you create it?
What were the character codes you tried to use for the characters?
Don't forget the capitalization of sharp s problem:  it's
one character in lower case but two (SS) in upper case.  -mod ]

     The point is that Unix does *not* support international
character sets in filenames.  It supports 7-bit USASCII.  So
let's leave that issue to rest.

[ There is strong interest on the part of a number of UNIX vendors
and users to make UNIX support international character sets in
a number of areas.  Anything that ties the filesystem or anything
else in the system to USASCII is not a step in a direction they want.
The file system at the moment supports uninterpreted strings of
bytes as file names, with the exception of /, null character,
names consisting solely of . and .., and those systems that
too helpfully zero the high order bit (4.3BSD, if I'm not
mistaken).  -mod ]

     I haven't yet heard of any serious use of full 8-bit bytes
for filenames on any other operating system, which, if you are
serious about supporting international character sets, you must
do.  There's this small problem of getting 8-bit (as opposed to
7-bit) ASCII through various pieces of hardware and networks
which think that the high order bit is parity...

     Can we now leave that particular argument to rest?

[ The Japanese seem to manage the eight bit problem on UNIX,
as modified both there and by AT&T to support the Japanese
language.  Most anyone who uses EMACS has the same problem,
and many of them seem to manage.  -mod ]

     Nobody has really answered the criticism that case
sensitivity is poor human engineering.

[ See Barry Shein's article, <[e-mail]>.  -mod ]

  Some people may disagree.
The same people may also feel that single character switches are
good human engineering.  Well, a lot of us who haven't been Unix
junkies for the past 15 years seem to feel otherwise.  The fact
that there is a controversy over the human engineering aspects of
a facility should suffice to indicate that there is a problem!

     Let's discuss these classes of issues.

[ If you have a survey that shows that most people find case insensitivity
easier to deal with, please present it.  If not, please refrain from
proof by character assassination.  -mod ]

-- Mark --
-------

Volume-Number: Volume 7, Number 66

From news  Fri Oct 17 11:36:21 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Oct 86 16:35:48 GMT
Draft-9: 2.3.folding

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Fri, 17 Oct 86 11:20:32 edt
Organization: AT&T Medical Information Systems, Columbus

Don Provan raises some interesting questions about foreign languages.
In general, I think we know how to do a case insensitive comparison
appropriately, by extending a function (I think it's called strcoll,
but I don't have my X3J11 draft handy) defined in ANSI C; the function
is like strcpy, but the destination buffer gets a translation of the
string that will collate properly when a lexicographic comparison like
strcmp is used.  If we extend this function to also translate to one
case (as appropriate) and allow each country to define its own function,
it's technically possible to ignore case.  Whether it's fast enough for
the UNIX filesystem is unclear, although this problem is not restricted
to UNIX.

I think it would be interesting to hear what other, case-insensitive
operating systems do about these issues.  What do MS DOS, or VM/CMS,
or VMS, or whatever, do with their case insensitive file names in
Europe, or Japan, or whereever?

If the answer is that file names are restricted to use the same character
set as in the USA, and that extra letters are disallowed, then we need to
know how well this is accepted by the users on other systems.  Maybe it's
good enough.  Do users in other countries often create files whose names
contain extra letters?  If they try, does the shell get in the way if their
letter happens to be "|", for example?

If the answer is that other operating systems have forced other countries
to put up with Americanisms, and that POSIX is an opportunity to break new
ground by handling other languages properly, then by all means let's do it
right.  This might require 8 bit characters in file names, for example.

Incidently, I've seen it claimed here that UNIX allows arbitrary byte
streams in file names.  Perhaps this is the intent, but in reality the
UNIX filesystem is far from a transparent path.  There are lots of
restrictions, some of which are:

    The slash character is special.
    The null character is special.
    Sequences of more than 14 chars not containing a slash are
        either illegal or only significant to 14 chars or
        significant to 256 chars, depending on the version of UNIX.
    Characters with the 8th bit turned on are not allowed.
    Since many commands take names beginning with "-" as flags,
        file names beginning with "-" don't always work.
    Since the shell treats many of the punctuation characters
        specially, file names containing space, #, $, &, *, (, ),
        [, ], ;, ', ", \, |, <, >. and ? do not always work
        properly.  Even if you quote them, the shell strips
        off the quotes, so that if multiple layers of shell
        are involved (for example, uux) it still fails.

Because some of these problems only affect certain uses of the filesystem
(whether or not you go through the shell, whether or not you're going
through a command that takes arguments) it's not unusual for casual users
to create a file and then have trouble using, renaming, or even removing it.
I recall that removing a file whose 8th bit has been set is a frequent topic
on net.unix.

If the filesystem were really transparent, the designers of /proc would
not have had to encode process ID's in ASCII digits, they could have
directly used the binary representation.

It's for these reasons that I feel that a conservative UNIX user should
restrict themselves to certain "reasonable" filename conventions; basically
using only lower case letters, digits, and a few save punctuation characters
such as . and - in their filenames.  Just because it's possible to put a
space in a file name doesn't make it a good idea.

    Mark

Volume-Number: Volume 7, Number 67

From news  Fri Oct 17 18:10:05 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Oct 86 23:09:37 GMT
Draft-9: 2.3.folding

From: mordor![e-mail] (John Bruner)
Reply-To: [e-mail]
Date: Fri, 17 Oct 86 14:39:08 PDT
Organization: S-1 Project, LLNL

It seems to me that there are three alternatives.  POSIX can specify
that conforming implementations must be case sensitive, must be case
insensitive, or may be either case sensitive or case insensitive.

If a conforming system must be case insensitive, then UNIX doesn't
conform.  If UNIX is to be included in the set of POSIX-compatible
systems, then case sensitivity must be permitted.

If a conforming system may be case sensitive or case insensitive,
then a lot of programs won't be portable.  Ignore for the moment
all existing UNIX code and consider new program development.  I
believe that programmers on one kind of system won't bother
with the library routines that are used to compare and/or convert
mixed-case names to monocase.  It doesn't matter what people "ought"
to do.  A well-known example of this effect is 4.2BSD.  The source
code is full of variables that should be declared "long" but --
since on the VAX "long" and "int" are identical -- are not.  In the
same way, optional case sensitivity will spawn code that only runs
correctly in the environment where it was written.

Therefore, I believe that case sensitivity must be retained, and
it should not be made optional.

Volume-Number: Volume 7, Number 68

From news  Fri Oct 17 18:42:55 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Oct 86 23:42:36 GMT
Draft-9: 2.3.folding

From: [e-mail] (Jim Cottrell)
Date: Fri, 17 Oct 86 16:57:43 EDT

> Having done a lot of case insensitive work, i've always felt that the
> UNIX case sensitivity was from laziness.  If i were to be charitable,
> i might go so far as to call it a shortcut.

I prefer to call it optimization. Case insensitivity must be enforced.
By my count, that's at least two instructions per character, plus loop
control (unless you have something like VAX's `move translated characters').
That ought to negate any speedup from hashing or name translation caching.

What is lazy is people refusing to learn the difference.

[ See previous comments about argument by character assassination.  -mod ]

    (Root Boy) Jim Cottrell        <[e-mail]>
    YOW!! I'm in a very clever and adorable INSANE ASYLUM!!


Volume-Number: Volume 7, Number 69

From news  Fri Oct 17 23:18:19 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 18 Oct 86 04:18:02 GMT
Draft-9: job.control

From: pyramid!utzoo!henry (Henry Spencer)
Date: Fri, 17 Oct 86 20:18:05 CDT

Apart from my overall objections to the concept of job control, there is
one thing seriously wrong with the P1003 job control proposal as posted:
it assumes that function names are distinct in at least the first 8
characters, as witness "setpgrp" vs. "setpgrp2" and "getpgrp" vs. "getpgrp2".
Note that an X3J11-conforming C implementation need distinguish only the
first 6 characters.  I would suggest revised names for the new primitives,
perhaps "setjpgrp" and "getjpgrp", with implementations which distinguish
8 or more characters providing "setpgrp2" and "getpgrp2" names as well for
maximum compatibility with existing mistakes.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 7, Number 70

From news  Sun Oct 19 10:51:13 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: case sensitivity in English
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 19 Oct 86 15:50:50 GMT
Draft-9: 2.3.folding

From: [e-mail] (Dan Franklin)
Date:     Fri, 17 Oct 86 9:16:27 EDT

Jim Balter once pointed out how much difference capitalization can make
in English: Communists do not believe in a Catholic God, but communists
may believe in a catholic god...

    Dan

Volume-Number: Volume 7, Number 71

From news  Mon Oct 20 04:13:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 20 Oct 86 09:13:29 GMT
Draft-9: 2.3.folding

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Sun, 19 Oct 86 23:11:35 edt
Organization: AT&T Medical Information Systems, Columbus

>If a conforming system may be case sensitive or case insensitive,
>then a lot of programs won't be portable.  Ignore for the moment
>all existing UNIX code and consider new program development.  I
>believe that programmers on one kind of system won't bother
>with the library routines that are used to compare and/or convert
>mixed-case names to monocase.  It doesn't matter what people "ought"
>to do.  A well-known example of this effect is 4.2BSD.  The source
>code is full of variables that should be declared "long" but --
>since on the VAX "long" and "int" are identical -- are not.  In the
>same way, optional case sensitivity will spawn code that only runs
>correctly in the environment where it was written.
>
>Therefore, I believe that case sensitivity must be retained, and
>it should not be made optional.

I'm sorry, but I don't buy this argument.  It seems to be based on
the assumption that case insensitivity will be implemented by the
use of subroutines for case-insensitive operations, with a different
user interface from that available today.  I think such an implementation
is silly, even if other operating systems may do it that way.

I'm talking about file names only.  I do not advocate even considering
making all of the user interfaces in UNIX case insensitive.  While it
might have once been a good idea to design them that way, I feel it's
far too late for someone to decree that all the upper and lower case
keys in, say, vi must be equivalent.

I think it's a given that existing code won't be rewritten to use new
interfaces, even if we come up with a wonderful way to do it.  Vi still
uses raw terminfo, even through curses would have been much easier and
better.  Also, there are lots of binaries out there that can't even be
recompiled.  Any solution to this problem must be in the kernel, or possibly
in libc underneath such subroutines as open, unlink, and chmod, (if you
have shared libraries or full source to recompile) or it won't work all
the time.

The obvious implementation is that the code in the kernel, when mapping a
filename to an inode number, to do a case-insensitive comparison when
checking each filename element in a directory.  This would be pretty
simple to add, although issues such as speed and international variations
would probably require a clever case-insensitive comparison, possibly
using a country-specific case mapping table with some flags or other
hacks to deal with single-multiple glyph mappings like SS to ess-tset.
There might even be a performance GAIN if creation of a directory entry
including calculating an appropriate hash function which is also stored
in the directory and used for initial comparisons.

I see no need to map everything to lower case when creating the directory
entry.  Let the entries be in mixed case; this allows more readable names.
I don't know what to do about sorting (e.g. in the shell or ls) - it might
be case sensitive or insensitive sorting, and good arguments can probably
be made for both.

The behavior I'm concerned about is that, if the user types, say, "mail"
and there's a command "Mail" in the search path, it should still work.
If the file "FooBar" exists and the user cats "foobar", because somebody
read that name over the phone, it should find it.

    Mark

Volume-Number: Volume 7, Number 72

From news  Mon Oct 20 04:23:40 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 20 Oct 86 09:23:21 GMT
Draft-9: 2.3.folding

From: pyramid!utzoo!henry (Henry Spencer)
Date: Mon, 20 Oct 86 04:07:24 CDT

> If the filesystem were really transparent, the designers of /proc would
> not have had to encode process ID's in ASCII digits, they could have
> directly used the binary representation.

This is rather a red herring, since they wouldn't have done this even if
it had been trivially possible.  The ASCII representation is a whole lot
more useful for human beings, and isn't a significant nuisance to programs.
The extra code needed to do it isn't much (yes, I have read it).

> It's for these reasons that I feel that a conservative UNIX user should
> restrict themselves to certain "reasonable" filename conventions...

Agreed, but that is not the topic of the discussion.  Standards must address
requirements other than those of conservative human users.  It is a serious
mistake for a standard to attempt to legislate morality.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry



Volume-Number: Volume 7, Number 73

From news  Mon Oct 20 04:26:24 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Job Control
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 20 Oct 86 09:26:04 GMT
Draft-9: job.control

From: pyramid!allegra!cbosg!osu-eddie!bgsuvax!schaefer (Stephen Schaefer)
Date: Thu, 16 Oct 86 13:05:33 edt

I'd like to offer some observations from my experience concerning
windows.  I am very comfortable using the wm window manager (by Robert
Jacob, enhanced by Matt Lennon and Tom Truscott).  The present design
relies heavily on pty's and the 'select' call of 4.[23]BSD.  I use a
9600 baud line with a 24*80 screen, which is quite sufficient.  I feel
no need at all for bit-mapping until I want to draw pictures, or
preview some typesetting, which has nothing to do with windows.  I'm
guessing that it takes about half a second to repaint my screen - the
same amount of time as vi takes to show the next screen full.  Far more
often, the window simply scrolls.
    I had a chance to work with a 5620 for a while.  While I was
directly connected at 9600 baud to a 4.2BSD 11-780, I told it to act
like a VT100 with a 70*88 screen.  I was more than happy - for
editing, I used the whole screen, for shell interaction I used a half
screen to cut down on update time, and because I'm usually working on
a minimum of two things at once.  Ghosting of the phosphor was far
more of a problem than speed.  I also used the 5620 with a 3B2, shell
layers, and a mouse.  Pulling windows around was fun for a while, but
it never became important to me, the way switching from window to
window has.  The bit mapping was good for drawing pictures and
previewing typesetting, but I never saw what it had to do with
windows.
    I haven't mentioned job control yet - I use it when it's
available.  I very often want a process to freeze until I find it
convenient to get back to it.  I am willing to entertain the
possibility that windows could take over much of that function, but
when I suspend, I am usually thinking "suspend", and it would take
some thought (or re-conditioning) to consider switching windows.  A
second consideration is that I use GNU emacs, and it significantly
faster to ^Z and fg than to quit and restart.  I don't understand the
accusations that ^Z is a "kluge", unless these people are referring to
the implementation, which I haven't studied.  It was utterly clear,
from the first time someone showed it to me: hit ^Z, ask to see your
jobs, now choose how or if to continue them (in foreground or
background), but be assured that they are still there until you
dispose of them.  I survive without it when I don't have it, but I use
it when I do have it.
    In sum: windows are good for multitasking *me*, and appear to
depend on pty's and maybe select(2).  Bitmapping is good for pictures,
but is irrelevant to a purely text environment - which is where I am
almost entirely.  Job control is good for suspending processes, and is
nice for avoiding the load time of large programs.  The three are
independent facilities.  An expensive, full-featured system would have
all of them.  Less expensive systems could be missing one or more of
them and still be Un*x.  If I had to choose the most valuable one it
would be pty's, but that is probably just my taste.

Volume-Number: Volume 7, Number 74

From news  Sat Oct 25 20:46:58 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: newsgroup constipation
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 01:46:41 GMT
Draft-9: mod.std.unix

There have been no articles in mod.std.unix since Monday because I've
been out of town.  I thought I had a guest moderator lined up, but that
didn't work out.  So there's quite a backlog which I will start funneling
out to the neworks now.

Volume-Number: Volume 7, Number 75

From news  Sat Oct 25 20:52:06 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 01:51:48 GMT
Draft-9: 2.3.folding

From: [e-mail] (Guy Harris)
Date: Mon, 20 Oct 86 10:49:33 PDT

Responses to a couple of messages:

>From Mark Horton:

> Any solution to this problem must be in the kernel, or possibly
> in libc underneath such subroutines as open, unlink, and chmod, (if you
> have shared libraries or full source to recompile) or it won't work all
> the time.

Any solution to this problem must be applied to operating systems other than
UNIX.  As John Bruner pointed out, mandating case-insensitivity will only
have the effect of removing UNIX from the list of standard-conforming
systems.  Changing the semantics of file names at this late date is unlikely
to meet with approval from many UNIX vendors and users.  For one thing, what
are you going to do about directories that contain files named, say,
"makefile" and "Makefile" (yes, they exist)?  You may feel that having
directories like this is a mistake, but declaring them to be a mistake isn't
going to make them go away.

There seem to be two issues here:

1) Should POSIX mandate case-sensitivity?

2) Should UNIX be changed to be case-insensitive if POSIX doesn't mandate
case-sensitivity?

These are rather separate issues.  A case can be made that POSIX should not
mandate case-sensitivity.  Applications must then not depend on
case-sensitivity.  This will affect programs that create files with names
other than those provided by the user.  It could also affect programs that
*read* directories, since they'd have to know that "foobar" and "FoOBaR"
refer to the same file.

I see great difficulty in changing UNIX to be case-insensitive, however.  It
certainly wouldn't pose any great *implementation* difficulties, but I would
not like to bet that no user or program would be greatly affected.

>From Mark R. Crispin:

>     It seems that the two sides in this issue boil down to this:
> . "gee, since we're defining a standard portable operating system
>   that isn't necessarily the present de facto Unix, let's fix
>   this case sensitivity cretinism"
> . "case sensitivity is what makes Unix better than any other
>   operating system, and only a cretin can't understand why this
>   is wonderful"

Not really.  A POSIX standard that does not *mandate* case-sensitivity need
not *forbid* it.  And I have seen *no* arguments that "case sensitivity is
what makes UNIX better than any other operating system."

>      Let's start by discarding the arguments which are bogus.
> The most glaring of these has got to be the international
> compatibility argument.  The only advocates of this argument seem
> to be pro case sensitivity Americans who have seized upon this as
> an argument to shore up their position without really thinking
> over the issue carefully.

Well, it may seem that way, but it isn't.  I admit to being a United States
citizen, but I am not unreservedly pro-case-sensitivity.  I see the merits
to both sides of the argument, but I see more problems with
case-insensitivity than with case-sensitivity.

>      Unix does not allow arbitrary strings in filenames.  Any
> number of "funny" characters must be within a quoted string.  I
> can't say
>     rm foo.bar;1
> I have to say
>     rm "foo.bar;1"
> Guess what.  A number of foreign keyboards use those "funny"
> characters to be non-English glyphs.

As the moderator pointed out, the shell, not the operating system,
interprets these funny characters.  Applications need not get file names
passed as arguments from the shell.  The office automation system we
developed at CCI had its own shell, which did no parsing of path names
whatsoever; the only characters it forbade were the slash and the null
character (because they are not allowed in UNIX filenames) and those
characters its forms package didn't allow you to type in (because we never
got around to changing it to do so).  I frequently used file names
containing blanks within this application, even though it made it
inconvenient to manipulate those files using commands typed at the UNIX
shell.

>      I have yet to hear of any organization in Japan using kanzi
> or hirogana or katakana in filenames.

I have a document in front of me from ASCII Corporation in Japan, describing
changes made to 4.2BSD to support Kanji and Kana.  It says:

    It is possible to create a file whose name contains Kana and/or
    Kanji characterss, since the file system and Kanji version of
    the shell support it.  However, we don't recommend such filenames,
    becasue it is impossible to handle such files from ASCII terminals.

The argument used against it would not apply if, for example, no terminals
attached to the machine were ASCII terminals and the site didn't expect to
export these files to machines with only ASCII terminals attached.  The
developers of it may be coming from a more "traditional" UNIX environment,
where you have many ASCII terminals attached to the machine and where you
frequently exchange files with other sites not running the same hardware and
software that you are running.  In an office environment, it may be possible
to provide everyone with a Kanji/Kana terminal, and it may not be as
important to worry about exchanging file with some random development
machine in the United States.

>   There are good reasons for
> this!  One is that there isn't a single way of representing
> written Japanese.  In older terminals, the high order bit when
> set indicated katakana (much as DEC VT220's use the high order
> bit for their "international characters").  Modern Japanese
> terminals use the JIS (Japanese Industrial Standard) system of
> ESCAPE followed by two bytes to define a 14 bit character.

The system they describe uses "Shift JIS" code for Kanji, and supports both
terminals that use this code and the regular JIS code for Kanji; it does
code conversion between the codes for JIS-Kanji terminals.

>      Some German keyboards use various 7-bit glyphs (I believe
> "@" is umlaut-a) for their umlauts and ess-tset.  Or, there's the
> VT220 system.  I just tried creating a file called Goethestrasse
> (using umlaut-o for "oe" and ess-tset for "ss") on my local Unix
> system using my VT220 clone.  It made "GVthestra_e", the 7-bit
> form.

The latter sounds like ISO Latin Alphabet No. 1; "umlaut-O" has the hex code
D6 and capital V has the code 56; 56 hex + 80 hex is D6 hex.  (I believe DEC
recommended the VT220 code set to ISO for standardization.)

>   Dare I mention that in German, only nouns (and the first
> word in a sentence) are capitalized?

The same is true of English; so what?

>      The point is that Unix does *not* support international
> character sets in filenames.  It supports 7-bit USASCII.  So
> let's leave that issue to rest.

As the moderator pointed out, this is not the case.  The kernel supports all
characters except slash and the null character, except for the 4.[23]BSD
kernel which (too helpfully) refuses to create files with characters in
their name that have the eighth bit set.  Certain UNIX utilities do not
handle 8-bit characters; this is not, however, an intrinsic characteristic
of the UNIX system.  I would ask European and Asian customers what they
wanted the UNIX system to do about character sets other than 7-bit USASCII
before I casually dismissed the possibility of supporting them.

>      I haven't yet heard of any serious use of full 8-bit bytes
> for filenames on any other operating system, which, if you are
> serious about supporting international character sets, you must
> do.  There's this small problem of getting 8-bit (as opposed to
> 7-bit) ASCII through various pieces of hardware and networks
> which think that the high order bit is parity...

Not all such pieces of hardware have this limitation.  The paper from ASCII
Corporation simply says "Kana and Kanji terminals must be set up to use 8
bit no parity mode."  If other terminals use a 7-bit encoding of an 8-bit
data stream, the terminal driver can do code translation transparently to
the rest of the system.

The fact that most OSes haven't solved these problems, and don't provide for
full 8-bit characters in file names, doesn't mean there is no demand for
full 8-bit characters in file names.  The users in non-English-speaking
countries may just have learned to get around this problem, and either use
English-language file names or approximate their native spelling in file
names.

Volume-Number: Volume 7, Number 76

From news  Sat Oct 25 20:57:36 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Case sensitivity in file names
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 01:57:22 GMT
Draft-9: 2.3.folding

From: seismo!allegra!phri![e-mail] (Roy Smith)
Date: Sun, 19 Oct 86 20:51:49 EDT

    I haven't been following this case-sensitivity discussion too
closely, so forgive me if this point has already been brought up.  Imbedded
capitals are useful for separating the components of multi-word filenames
without wasting valuable characters.  Consider the following:

    1) UnixCaseDebate
    2) unixcasedebate
    3) unix_case_debate (or trivial variations like unix.case.debate)

    I think most would agree that #2 is much less readable than either
of the others.  Whether #1 or #3 is easier to read is in the eye of the
beholder, but consider that the former is a valid filename in 14-character
systems, while the latter is not.

    All this aside, it has been stated over and over again that the job
of a standard is to agree on something which is the most compatible with
the most existing implementations.  I don't know of any existing Unix
implementations that have case-insensitive filenames, so why start now?

    It has already been pointed out by several people that various
layered Unix products, such as Eunice, have dealt with the problem of
enforcing (or, if you prefer, "allowing") case sensitivity with an
underlying OS that doesn't.  On the other side of the coin, application
programs like Emacs provide case-insensitivity in filenames with a
case-sensitive OS underneath.  Thus, the argument that having a
case-insensitive file system makes Unix more portable just doesn't hold
water.

    So, what do you have?  An idea that doesn't provide any added
portability, or any added capability that can't be provided by an
application, and is incompatible with most (all?) existing implementations.
Sounds like a bad idea to me.

Roy Smith, {allegra,philabs,cmcl2,sun}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016



Volume-Number: Volume 7, Number 77

From news  Sat Oct 25 21:00:51 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: case sensitive file names
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:00:37 GMT
Draft-9: 2.3.folding

From: @SUMEX-AIM.ARPA:MRC@PANDA  (Mark Crispin)
Date: Mon 20 Oct 86 05:42:50-PDT
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: [phone]

     The XDE Lisp machine file server I use has a file system of the
sort that Mark Horton describes.  That is, it accepts and preserves
mixed case in filenames, but in name selection it does a case-independent
match.

     I find that on this file server I am much more likely to use a file
name such as TokyoPaper.FirstDraft.  In fact, this file server encourages
me to mix case like this freely, since there is no cost in doing so.  I
can edit "tokyopaper.firstdraft" or "TOKYOPAPER.FIRSTDRAFT" or even
"tOKYOpAPER.fIRSTdRAFT" and the system is still smart enough to figure
out I mean TokyoPaper.FirstDraft.

     On the DEC-20 and Unix file servers, it's single case and hyphens.
I end up using something like "tokyo-paper.first-draft".

     These were personal observations.  However, I know for a fact that
nobody uses mixed case on our Unix-based file server.  The Leaf (Xerox
Lisp machine file access protocol) server on Unix was modified to coerce
all filenames to be entirely lowercase on the Unix machine's disk and to
coerce it back to all uppercase in the other direction.  There were/are
two reasons:
 (1) transfers to/from the third file server, a DEC-20, were hopeless
     otherwise since the Unix system would insist that two identical files
     were different because the case of the names didn't match
 (2) the users found the case dependence to be a serious problem.

-- Mark --
-------

Volume-Number: Volume 7, Number 78

From news  Sat Oct 25 21:05:15 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: extern name length
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:05:01 GMT
Draft-9: 8.0

From: [e-mail] (VLD/VMB)
Date:     Mon, 20 Oct 86 9:44:19 EDT

If it doesn't support 32-character extern name uniqueness, it isn't POSIX.
1003.1 imposes requirements on a C implementation beyond those of X3J11.

I agree, however, that the names ending in "2" are ugly and that better
names might be chosen for them.

Volume-Number: Volume 7, Number 79

From news  Sat Oct 25 21:09:08 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: window size
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:08:53 GMT
Draft-9: windows

From: [e-mail] (VLD/VMB)
Date:     Mon, 20 Oct 86 10:00:13 EDT

Many of us have long outgrown the fixed-size, constant-width font model
of text characters.  Such ideas as pagination to multiples of N text
lines are not as useful as they might once have been.  I would hope
that simplistic models of terminal text do not become more deeply
embedded in specifications such as POSIX.  Limitations due to
insufficiently general models are one of the worst problems with
existing systems; we can do better.

As to what TIOCGWINSZ should return: for some situations character
cell array dimensions are appropriate; for others pixel array size
is appropriate.  It would be best to supply both, with the explanation
that a "pixel" may just be a character cell for old-fashioned terminal
devices (in which case both sets of dimensions would have the same
numerical values).

Volume-Number: Volume 7, Number 80

From news  Sat Oct 25 21:13:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: case mapping
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:12:50 GMT
Draft-9: 2.3.folding

From: [e-mail] (VLD/VMB) (Doug Gwyn)
Date:     Mon, 20 Oct 86 10:33:00 EDT

The reason strcoll() expands a text string to as much as twice its
original length for collating purposes, rather than mapping it to
a lowest-common-denominator form (such as case folding) is because
it is believed that the former can always be done successfully,
whereas lowest-common-denominator same-length mapping is known to
be inadequate.  Note also that the actions of strcoll() depend on
a dynamically-changeable selection of "locale" information.  So
strcoll() is a red herring in this debate.

UNIX variants that clear all but 7 bits in each char of a filename
are examples of systems that try too hard to be "helpful" based on
too limited a view of the world.  They should be fixed, as I'm sure
the Japanese have already suggested.

Arguments based on characteristics of the shell or of command-line
option parsing are beside the point; we're talking about what the
kernel does or should do about filenames.

The UNIX kernel was deliberately designed to be not much more than
an I/O multiplexer.  As with limited government, the theory is that
the kernel should do only those things that cannot be done at the
application level.  This includes coordination of shared resources
but NOT enforcement of technically unnecessary ideas about what is
appropriate for applications to be doing.

The fact that most UNIX implementations, including systems from
Berkeley and ATTIS, do not fully adhere to this design philosophy
is also irrelevant; they should perhaps be fixed.  Certainly a
standard such as POSIX that establishes a minimum common environment
has no business imposing limited application models across the board.
If POSIX is done properly, it should be even more minimalist than
8th Edition UNIX.


Volume-Number: Volume 7, Number 81

From news  Sat Oct 25 21:20:11 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: X3 display committee
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:19:56 GMT
Draft-9: X3H3.6

From: nike!ll-xn!mit-amt!mit-eddie!frog!jim (Jim Isaak, IEEE P1003 Chair)
Date: Fri, 17 Oct 86 20:33:40 EDT

For general information, an X3 committee has been formed to deal with
standards for display management.  This includes windowing controls.
It is chaired by John Butler of Microsoft.  Datamation reports that they
are developing a model based on MS/Windows rather than X.WINDOWS or
Sun's NeW(e)s(t) suggestions.  It is not clear how this might related
to 1003 and/or other standards.


Volume-Number: Volume 7, Number 82

From news  Sat Oct 25 21:23:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: 8 bit characters
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:23:39 GMT
Draft-9: 2.3.folding

From: nike!ll-xn!mit-amt!mit-eddie!frog!jim (Jim Isaak)
Date: Mon, 20 Oct 86 16:52:03 EDT

re: mod.std.unix note of Mark Crispin

Charles River has been shipping 8 bit "UNIX System V" Derived systems
for some 5-6 years, and with a substantial user base in Japan and
China.  It is important, significant, and very useful that the full
8 bits is carried throughout the file system.  Since terminals tend
to display what is input, and since a single site tends to use compatible
terminals the system does not need to be aware of what character sets
are being used -- if it's Kanji in its Kanji out .... as long as we
don't start sneaking in automatic conversions or stripping the 8th bit.

This alone does not speak to the uppercase/lower case point.  While it
is clear that we  (both as vendors and the standard) would be foolish to
not permit at least 8 bit characters, it might still make sense to do
a conversion of the "a-z" range to "A-Z" ... at least in theory; any
other abuse of the bit ranges would seem to be un-acceptable.

So, the question comes down to "a-z" vs "A-Z"; the answers should look
forward to a much broader base of users, and to the systems of the
1990's.  From a system perspective, every thing I see  coming out
can support upper and lower case, so there is little incentive for
case-folding there.  Also, I think the broader range of users (not us
computer folk) are used to their local conventions for upper and lower
case, and would want to project these onto a given system.  That probably
means not folding the cases.

Volume-Number: Volume 7, Number 83

From news  Sat Oct 25 21:26:45 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:26:26 GMT
Draft-9: job.control

From: seismo!munnari!yabbie.rmit.oz![e-mail] (Ian Donaldson)
Date: Tue, 21 Oct 86 10:39:40 EST

> From: im4u!caip!hplabs!hpda!hpisoa1![e-mail] (Dave Lennert)
> Date: Thu, 9 Oct 86 14:06:30 pdt

>        saved process group ID
>          An    active process has a saved process group ID that is
>          set to the    saved process group ID of the parent
>          process at    the time of creation of    the process (via
>          the fork()    function).  It is reset    to the process
>          group ID of the process when the process successfully
>          calls one of the exec functions.

What is the significance of the "saved process group ID"?  How is
it different to the normal process-group-ID?  Who uses it?

>        In section 3.2.2.2 Description of the _exit function replace
>        the paragraph:

>        with:
>
>          If    the process is a session process group leader, the
>          SIGHUP signal may be sent to each process that has    a
               ^^^ should be replaced by the word "will"
>          process group ID equal to that of the calling process;
>          also, all such processes may have their process group
>          ID    set to zero.
>
>          If    the implementation supports the    job control option
>          and if the    calling    process    has child processes that
>          are stopped, they will be sent SIGHUP and SIGCONT
>          signals.
>

I disagree with the proposal on the handling of _exit processing for
job control.  It should be possible to not have to know in advance
that you wish to log-off and leave something running that you started
in foreground and later shifted to background.  This is a KEY feature
of job control.

vhangup() will provide clean terminals on a bsd system,
and we have improved vhangup further to not just turn off READ/WRITE bits,
but to actually redirect the file references to /dev/null (which has
the advantage of also dropping DTR reliably).
Infinite-loop processes don't cause problems with system-response because
they are automatically niced (something that is long-needed in UNIX systems).

I see no mention of a vhangup equivalent in this proposal segment, but
then again, I haven't seen the whole of P1003 either.

I find the SIGHUP being sent by exiting processes to sub-proceses
a plain nuisance, and it does nothing for productivity.  Nohup(1)
is effectively obsoleted by job control, since the process won't
receive signals from terminals when they are in background anyway.

One if the KEY things about job-control is that you don't have
to "know in advance" what you plan to do.  Nohup(1) requires that
you do known in advance, and with the above proposal, nohup(1) IS
required if you want to leave jobs running when you log-off.

The SIGHUP and SIGCONT signals are only sent to processes in the
terminal process group when modem carrier disappears on a BSD system.
Children of init that are stopped are also sent SIGHUP's and SIGCONT's.
Children of init that aren't stopped aren't sent anything.

Ian Donaldson

Volume-Number: Volume 7, Number 84

From news  Sat Oct 25 21:30:09 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (Brett Galloway)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:29:54 GMT
Draft-9: job.control

From: pyramid!decwrl!qubix!wjvax!brett
Date: Mon, 20 Oct 86 11:03:18 pdt
Organization: Watkins-Johnson Co., San Jose, Calif.

In article <[e-mail]> Hentry Spencer writes:
>From: pyramid!utzoo!henry (Henry Spencer)
>Date: Fri, 17 Oct 86 20:18:05 CDT
>
>Apart from my overall objections to the concept of job control, there is
>one thing seriously wrong with the P1003 job control proposal as posted:
>it assumes that function names are distinct in at least the first 8
>characters, as witness "setpgrp" vs. "setpgrp2" and "getpgrp" vs. "getpgrp2".
>Note that an X3J11-conforming C implementation need distinguish only the
>first 6 characters.  I would suggest revised names for the new primitives,
>perhaps "setjpgrp" and "getjpgrp", with implementations which distinguish
>8 or more characters providing "setpgrp2" and "getpgrp2" names as well for
>maximum compatibility with existing mistakes.

Let's not force all variables to be distinct in the first 6 chars.  The
proper fix is to force a conforming C compiler to be more discriminating.
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett


Volume-Number: Volume 7, Number 85

From news  Sat Oct 25 21:34:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: case sensitivity
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:34:02 GMT
Draft-9: 2.3.folding

From: seismo!bellcore!jgs (Jeff Smits)
Date: Tue, 21 Oct 86 16:32:57 edt

One of the nice things about the UNIX system, is that the operating system
doesn't try to define precise semantics of the  use of its facilities.
"A path-name is a null-terminated character string starting with an optional
slash (/), followed by zero or more directory names separated by slashes,
optional followed by a file-name." (From the System III reference manual)
That is all the semantics attached to the concept of a path-name.

By leaving the semantics simple, it makes it easy to support file/path-names
with international characters in them.  UNIX Pacific offers a source product
called JAE 1.0 (Japanese Application Environment) based on System V, Release
2.1.0.  Included in its features is support for Japanese file-names as
documented in the Future Directions section of SVID Issue 2.
The basic concept is that the US ASCII code-set is always present contained
in the code-set range 001-0177(octal).  The range above 0177 (0x200-0x377 on
an eight-bit machine) is reserved for international characters.  No changes
were needed to the core operating system to support this.  Many of the utilities
function correctly with these code-sets.  This is all because there were no
additional semantics attached to the meaning of a character in a path-name.

It is the terminal driver's responsibility to convert the data received from
an international terminal into this internal representation.

The important point is that the operating system has no knowledge of the
code-set the path-names are written in.  The only assumption made about a
path-name is that the '/' character separates components in a path, and
the NULL character terminates the path.

If the standard changed to support case translation, it would be building an
code-set bias into an operating system implementation.  It would be difficult
to support the variety of code-sets with that type of conversion being done
in the operating system.

Due to international considerations and the fact that current practice
(both System V and BSD) support case sensitive file-names, I think
the current P1003 draft is correct with respect to case sensitivity.


                        Jeff Smits
                        AT&T Information Systems
                        ..!attunix!jgs
                        (201)-522-6263
                        190 River Rd.
                        Summit, NJ 07901

Volume-Number: Volume 7, Number 86

From news  Sat Oct 25 21:58:00 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix,net.unix,net.usenix,net.unix-wizards
Subject: WeirdNIX
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Followup-To: mod.std.unix
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 02:57:42 GMT
Draft-9: Weirdnix

[ This is being crossposted to several newsgroups by request.
Followups should be to mod.std.unix, i.e., mailed to ut-sally!std-unix,
or sent as mail replies to Donn Terry at hplabs!hpfcla!donn or
the paper mail address below.  -mod ]

From: utah-cs!hplabs!hpfcla!hpfcdc!donn (Donn Terry)
Date: Mon, 20 Oct 86 16:54:44 mdt

            WeirdNIX

    ... or destructive QA of a standard.

The IEEE P1003 committee is offering prizes for the the best new and
technically legal interpretation of the POSIX(*) standard which
nevertheless violates the intuitive intent of the POSIX standard.

The intent is to find how the standard might be misinterpreted, and then
to correct the errors that the misinterpretations point out.  Like
destructive testing of hardware, you stress it until it breaks and then
fix what broke so you can then stress it further.

The criteria for judging the misinterpretations are:

It must be an interpretation of the P1003.1 POSIX Trial Use standard (as
published by IEEE) which conforms completely to the standard.  For the
purposes of the contest, Appendices C.5, E.1 and J are included as part
of the standard, but no other Appendices.

It must be represented as a detailed description in either pseudo-code
and or text as how an implementation could behave so as to conform with
the standard and still do "the wrong thing".  Annotation as to why the
interpretation is considered legal by the submitter will be of
significant value in judging.

Interpretations must be of topics discussed in the standard.  Areas that
are not covered by the standard are not eligable.  Interpretations which
use some features of the standard and then take advantage of something upon
which the standard is silent (and thus should not be) will be of significant
value.

If there are similar entries, postmark dates will be used.  If the entry
is submitted electronically, the postmark date will be the time and date
of mailing.  In case of a tie, the entry with the earliest postmark will
be used.

The winners will be judged by a subset of the IEEE P1003 working group,
and the members of that group are not eligable for prizes.  Members of
the working group for the purposes of this contest are those individuals
who attended either 2 or more of the most recent 4 working group meetings,
or who attended in Palo Alto.  The decision of the judges is final.

Prizes will be awarded to the "best" and "most demented" interpretations.
"Best" is an interpretation that is legal and which is "likely", in that
one could reasonably make the mistake and implement a system which did
that.  "Most demented" is a legal interpretation that would not actually
be implemented because it violates common sense.

More than one first prize in each category may be awarded if, in the
interpretation of the judges, the best submittals are of comparable quality
and are distinct problems.  Zero or more second prizes may also be awarded.

The first prize consists of:
    + Hewlett-Packard has agreed to donate some HP 16C calculators.
    + having your name in a place of honor in the acknowledgements
      section of the P1003.1 final use standard,
    + a copy of the final use standard (with your name in it!)

Second prizes (if any) consist of:
    + special mention in the acknowledgements section of the P1003.1
      final use standard,
    + a copy of the final use standard (with your name in it!)

The winners will be announced at USENIX/UniForum in January.  Deadline for
arrival of paper submittals is Friday, December 8th.   Submittals arriving
after that date will be considered only if they are in electronic form so
they can be judged remotely.  No submittals will be considered after
January 1, 1986.  Submittals should be sent either by mail (before
December 8th) or by electronic mail to:

        Donn Terry
        co-Chair P1003.1
        Hewlett-Packard Co.
        3404 E. Harmony Rd.
        Ft. Collins, Co. 80525

        {hplabs!}hpfcla!donn

The submitters of all interpretations that are considered for prizes
(first postmark and legal) will be listed as contributors to the standard.

Submitting a proposal to the contest releases it to be used by IEEE both
to improve the standard, and to publish it as it sees fit.

A sample submittal follows (with thanks to Hal Jespersen).  The exact
form is not critical, but this submittal, were it eligable, would definitely
get consideration for a prize.  (In any case, it will be fixed!)

    Problem:
        getcwd() can legally return "."

    Explanation:
        getcwd() returns a pointer to the pathname of the
        current working directory.  The definition of
        pathname allows the dot directory as a valid
        pathname.  Returning dot from getcwd() is an
        effective no-op, but legal.

    Proposed Correction (optional):
        Add the following as a second sentence in sect 5.2.2.2:
        "The pathname that is pointed to is a full pathname,
        expressed relative to the root directory."

Donn Terry

Volume-Number: Volume 7, Number 87

From news  Sat Oct 25 22:08:50 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix,net.unix,net.usenix,net.unix-wizards
Subject: Re: WeirdNIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: hpfcla![e-mail]
Followup-To: mod.std.unix
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 03:08:23 GMT
Draft-9: Weirdnix

[ This is crossposted to several newsgroups by requests (it's a followup
to a similar article).  Further followups should go to mod.std.unix, i.e.,
be mailed to ut-sally!std-unix.  Replies should go to Donn Terry.
-mod.std.unix moderator ]

From: utah-cs!hplabs!hpfcla!hpfcdc!donn (Donn Terry)
Date: Mon, 20 Oct 86 16:54:44 mdt

The schedule on this is a little tighter than I'd like it to be, but
after getting all the approvals, it only leaves about 1.5 months to
run the contest if we close things off in time to judge at the December
P1003 meeting.  Thus the fact that electronic topics will be accepted later.
We can continue the judging via mail afterwards, if there is stuff to judge.

If the people who had the original idea (who may wish to remain anonymous)
want credit, let me know.  This idea is sufficiently "unusual" that
they may not want to take the blame#####credit :-) .

Please pass this on to your friends.  The more submittals, the better.

Donn Terry

Volume-Number: Volume 7, Number 88

From news  Sat Oct 25 22:19:38 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: case sensitive filenames
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 26 Oct 86 03:19:05 GMT
Draft-9: 2.3.folding

From: [e-mail] (Paul E. McKenney)
Date: Thu, 23 Oct 86 17:27:21 pdt
Organization: SRI, Menlo Park, CA.

Ok, how about a compromise proposal?

Keep roughly the same case-sensitivity in the kernel interface that exists
now.  This means that (for example) 'unlink("abc")' and 'unlink("ABC")' will
remove two different files.

Keep the normal shell interface for filenames.  This means that (again, for
example) 'rm abc' and 'rm ABC' will again remove two different files.

Make escape completion case insensitive.  (Escape completion is used in some
versions of BSD 4.x csh, perhaps elsewhere also.  It allows a user to
type the first part of a filename (or command name) and then hit
ESC.  The system will complete the filename as best it can.  If it cannot
unambiguously determine the filename from the part given by the user, it
will beep after having supplied as much of the filename as it can without
problems with ambiguity.  There is also usually a feature that allow the
user to display all filenames that match what he has typed so far --
control-D serves this function in some variants of BSD 4.2 csh.)

In other words, if a user types 'rm abc<ESC>' (where <ESC> represents the
ESC key), and there is a file named 'ABC', and there is no other file that
matches the pattern '[aA][bB][cC]', the shell (-not- the kernel) will
backspace over the 'abc' and overwrite it with 'ABC' so that the command
line will look as if the user had typed 'rm ABC'.  The user may then
hit RETURN if he wishes to execute the command, or he may further edit
the command line (using his usual backspace/delete, etc. characters).

This escape-mapping facility should be supplied in a library routine so that
application programs can easily act the same way.  It would be nice if such
a function could work with keywords, hostnames, etc. as well as filenames.

This proposal has the following advantages:

o    It does not impact existing software (addition of the case-insensitive
    ESC does not add any functionality, it just makes it easier on users).

o    It answers Mark Horton's 'filename-over-the-phone' problem
    <[e-mail]> (just tell the user to type 'foobar<ESC>').

o    It allows users from a case-insensitive environment a helpful tool
    to ease their transition (let's face it -- if it is different than
    whatever you are used to, it ain't friendly -- regardless of whether
    you are used to case sensitivity, case insensitivity, or hieroglyphics).

o    Removes the need for millions and millions of 'upper()' calls in
    application code mentioned by Dan Libes <[e-mail]>
    (although the additional code to do good escape-completion is far
    from trivial!).

o    Removes the need for 'isfsense()' or 'isflegal()' (Chris Lent,
    <[e-mail]>) since all implementations could use the same
    definition of legal characters in a pathname.  Note that 'isflegal()'
    is still useful for programs that are trying to be portable across
    different operating systems.

This proposal leaves the following two issues unresolved:

o    Whether the eighth bit on characters within a filename should be
    significant.  The developers of BSD 4.[23] must have had some good
    reason for making it insignificant, but the only reason that comes
    to mind is that most terminals cannot easily specify the eighth bit
    (just like some older terminals cannot easily specify lower case!).

o    Whether there should be some escaping mechanism to allow slash ("/")
    and ASCII NUL in a filename.  I cannot think of a reason for allowing
    this that seems worth the trouble -- any comments?


            Paul E. McKenney
            [e-mail]
            {pyramid,rutgers,ucbvax!hplabs}!sri-unix!mckenney

Volume-Number: Volume 7, Number 89

From news  Sun Oct 26 22:22:18 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names: what do other systems do
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 27 Oct 86 04:21:54 GMT
Draft-9: 2.3.folding

From: seismo!mcvax!guido (Guido van Rossum)
Date: Thu, 23 Oct 86 23:19:13 +0100

In article <[e-mail]>, Mark Horton writes:
>I think it would be interesting to hear what other, case-insensitive
>operating systems do about these issues.  What do MS DOS, or VM/CMS,
>or VMS, or whatever, do with their case insensitive file names in
>Europe, or Japan, or whereever?

Since you are asking:

I know quite well what two other case-insensitive systems do.  They take
extreme positions (while both being case-insensitive!).  To wit:

MS-DOS:

- Everything is in upper case (lower case is accepted by system calls
  but you get upper case back by directory searches etc.).
- Allows only alphanumerics and a very small set of punctuation
  characters; the rest are sort of ignored or considered as terminators!
- This means Germans etc. are in the same position as just after the
  invention of the telegraph.  (The Dutch don't particularly mind
  because they use few special characters and never know exactly where
  an umlaut should go anyway (we don't call it an umlaut, actually, but
  the Dutch word wouldn't make sense to most readers of this message).)

Apple Macintosh:

- The case given when a file was created is retained in the directory
  listing so it is possible to make a file name stand out by calling it
  "READ ME" (yes, with spaces!).
- All characters of the Mac's 8-bit character set are allowed, except
  the colon, which serves as a pathname delimiter ('/' in Unix).  This is
  USASCII extended with all sorts of odd characters used in all sorts of
  foreign languages (as long as they use the latin alphabet as a base).
  Even chracters that don't have a representation in the commonly used
  fonts are allowed; even the null character, (although this possibility
  necessarily disappears in the C interface).
  There is a mapping between the cases which can be used for various
  purposes; A and a correspond in this mapping, but accented characters
  are not the same as their other case counterparts (I believe --
  someone borrowed my copy of Inside Macintosh).  This mapping is used
  when files are opened, etc.  There is also a collating sequence for
  arbitrary strings which can be changed by different countries.
- Germans, French and Swedes should be perfectly happy with this, unless
  they happen to be case-sensitivity-freaks.  I don't know about the
  Japanese, but they could get away quite well if they use a different
  mapping to character glyphs (which is quite simple to do on the Mac).

(BTW, I think Apple has also designed decent solutions to other
internationalization issues -- their date and time notation, and probably
that for currency also, can be adapted to any of the European countries
in which they sell computers!)

Oh, just in case votes are taken: I am *for* case sensitivity.
John Bruner put it quite well.

    Guido van Rossum, CWI, Amsterdam <[e-mail]>

Volume-Number: Volume 7, Number 90

From news  Sun Oct 26 22:26:48 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: A convention for -file
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 27 Oct 86 04:26:31 GMT
Draft-9: 1003.2.getopt

From: [e-mail] (Matthew P Wiener)
Date: Fri, 24 Oct 86 14:27:50 PDT
Organization: University of California, Berkeley

In article <[e-mail]> Mark Horton writes:
>    Since many commands take names beginning with "-" as flags,
>        file names beginning with "-" don't always work.

There's a real easy fix to the current random collection of special
flags that handle filenames beginning with a dash: always interpret
two dashes at the beginning of a command line argument as the name for
the file obtained by eliding the two dashes into one.  Thus

% rm --xyz ----xyz

would mean remove -xyz ---xyz, etc.  It's completely unambiguous,
until some clown comes up with flags needing two dashes.  Similarly
for ++file with commands using + flags.

ucbvax!brahms!weemba    Matthew P Wiener/UCB Math Dept/Berkeley CA 94720

Volume-Number: Volume 7, Number 91

From news  Sun Oct 26 22:31:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 27 Oct 86 04:31:05 GMT
Draft-9: job.control

From: [e-mail] (Bill Shannon)
Date: Sat, 25 Oct 86 00:19:53 PDT

> From: [e-mail] (Robert Reed)
> Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
> Date: 15 Oct 86 12:23:31 PDT (Wed)
>
> Naive programs should have access to window size as character information,
> but there are programs which do not manipulate windows which need window
> size information in pixels.

I'm still waiting to hear about such programs that aren't dependent on
the particular window system they are running under.

> Whether the tty system does know about pixels or not, it should.  If the
> window size information (in character units) is going to be accurate, window
> sizes must be restricted to integrals of character size.  With straight ttys
> this is no problem, but if the system supports font changing, character size
> can vary.  Rather than require one call to find the window size and then
> another call to find out what the units are, this information should be
> consolidated into a single place.

If you want both at once, the window system can do the consolidation.

The tty driver should not know about pixels.

                    Bill Shannon

Volume-Number: Volume 7, Number 92

From news  Sun Oct 26 22:36:37 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: window size
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 27 Oct 86 04:36:14 GMT
Draft-9: windows

From: [e-mail] (Guy Harris)
Date: Sun, 26 Oct 86 15:16:30 PST

> As to what TIOCGWINSZ should return: for some situations character
> cell array dimensions are appropriate; for others pixel array size
> is appropriate.

Bill Shannon's point was that those applications for which pixel array size
is important are not necessarily going to be talking to a terminal-like
interface.  It is certainly *possible* to do graphics and window management
through such an interface; whether this is *desirable* is another matter.
Until it is established that all implementations will provide access to
graphics or a window system through the terminal interface, it is
inappropriate to require the terminal interface to supply data not
applicable to plain text characters.

Volume-Number: Volume 7, Number 93

From news  Mon Oct 27 14:13:35 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names (8 bit file names)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Keywords: international filename eightbit characters
Summary: The problem is the shell, not the file system.
Date: 27 Oct 86 20:13:10 GMT
Draft-9: 2.3.folding

From: seismo!enea!tut!intrin.uucp!jty (Jyrki Yli-Nokari)
Date: Mon, 27 Oct 86 20:54:42 -0200
Organization: Intrinsic Oy, Tampere, Finland

There seems to be misunderstanding about Unix not accepting 8 bit characters
in file names.

I would like to point out that Unix is perfectly happy to include
ANY 8 bit characters in the file name, EXCEPT slash '/' or null '\0'.

[ Depends on which system you're referring to:  some really do
strip the eighth bit in the file system, not in the shell.
Though there are many shells that also strip that bit,
as you point out.  -mod ]

The REAL problem is the shell that strips the 8:th bit off for its
own purposes.

At least IBM's AIX and HP's HP-UX have fixed this problem.

Regardless of the case sensitivity we MUST start from the fact
that characters are made out of at least eight bits, not seven = USASCII.

Now that I use 7 bit modified ascii character set,
the O umlaut in my terminal is really a backslash '\'
as far as Unix is concerned.

Try explaning that to a casual end-user, who wants to create a file
called '\rkki'.

Volume-Number: Volume 7, Number 94

From news  Mon Oct 27 15:05:39 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: A convention for -file
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 27 Oct 86 21:05:29 GMT
Draft-9: 1003.2.getopt

From: [e-mail] (Guy Harris)
Date: Mon, 27 Oct 86 12:44:39 PST

> There's a real easy fix to the current random collection of special
> flags that handle filenames beginning with a dash:...

There's another fix, already implemented by all the versions of "getopt"
running around - an argument of the form "--" means no other arguments are
to be interpreted as flags, regardless of their form.  Since this one has
already been implemented by many commands, it is preferable.

Volume-Number: Volume 7, Number 95

From news  Mon Oct 27 22:40:47 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: missing features from POSIX
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 04:40:16 GMT
Draft-9: 1003.2.getopt 1003.2.popen

From: utah-cs!cbosgd!cbosgd.ATT.COM!mark (Mark Horton)
Date: Mon, 27 Oct 86 20:51:58 est

In comparing various C libraries and standards, I discovered several
important routines that are in neither POSIX nor X3J11.  I'd like to
find out why they are missing.  Would you please either answer these,
ask the appropriate person, or post to mod.std.unix?

[ Post.  Most of them are higher level than X3J11 or 1003.1 address.  -mod ]

Some of these functions were explicitly created to enhance portability,
so it seems surprising to omit them.

getopt    This function is now present in System V and in 4.3BSD.  Two
    public domain implementations have been released, one by
    Toronto and one by AT&T.  AT&T is pushing getopt as a standard
    way to process arguments.  Yet it's unwise to use it if you
    can't be reasonably assured that it will work everywhere.

    I can even imagine that another operating system might support
    getopt to crack their own native conventions; for example, on
    MS DOS it might check for options beginning with / (or maybe
    even with the switch char.)  On a MacIntosh, it might be possible
    to get options from mouse conventions or a menu (possibly with
    the use of an additional table for menu labels.)

curses    Both 4BSD and System V have curses libraries which are largely
    compatible, making curses the most portable and highest level
    way to write screen oriented software.  Many curses functions
    were explicitly included to assist portability.  Yet a system
    can conform to POSIX and not provide any screen handling support.

    I would recommend that some appropriate subset of curses be
    specified by POSIX.  The subset should be the intersection
    of 4BSD and System V curses (essentially this means 4BSD minus
    the unportable features) with a dozen or so System V functions
    that enhance portability included (such as erasechar and cbreak.)

popen    This is part of standard I/O, but specific to UNIX, it's in
    every version of UNIX I know of.  Yet it's in neither X3J11
    nor POSIX.

I also ran into problems with <memory.h> and memccpy, but these are
conflicts between SVID and X3J11 which I will direct elsewhere.

    Mark

Volume-Number: Volume 7, Number 96

From news  Tue Oct 28 11:17:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: A convention for -file
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 17:17:13 GMT
Draft-9: 1003.2.getopt

From: [e-mail] (Matthew P Wiener)
Date: Mon, 27 Oct 86 23:12:03 PST
Organization: University of California, Berkeley

In article <[e-mail]> Guy Harris writes:
>There's another fix, already implemented by all the versions of "getopt"
>running around - an argument of the form "--" means no other arguments are
>to be interpreted as flags, regardless of their form.

But such breaks on commands that take flags after the argument name, like
cc, lxref, od.

>                                Since this one has
>already been implemented by many commands, it is preferable.

Huh??  Why bother debating standards then?  I once got the argument that
integer division should round towards 0, not towards minus infinity, since
that's how Fortran did it.  I was new to the net then, and I was stunned.

I do not count appeal to the past or even the present as the definition of
preferable, although I agree that it can be a major factor.  But I dislike
it when it is paraded as THE reason for saying its preferable.  Is UNIX
supposed to turn into an official fossil now?

I say my suggestion is cleaner and more versatile, thus it is preferable.
The required reprogramming would not be that complicated--just a minor
nuisance.

But if you wish appeals to history, my suggestion is after all the same
as the ancient doubled quote => single quote within quoted strings con-
vention from days of yore.  In retrospect, it's perhaps a bit surprising
that something like this wasn't adopted from the beginning.

Not that I care.  *I* don't put dashes at the beginning of my file names.
(Joke, everyone, just a joke.)

ucbvax!brahms!weemba    Matthew P Wiener/UCB Math Dept/Berkeley CA 94720

Volume-Number: Volume 7, Number 97

From news  Tue Oct 28 11:29:44 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: End of Volume 7
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 17:29:30 GMT
Draft-9: mod.std.unix

This is the end of Volume 7 of mod.std.unix.  These volumes are
purely for administrative convenience; this one is ending simply
because the archive has gotten too bulky for me to look through
conveniently.  Feel free to continue any discussion in the new
volume or to start new ones.

Volume-Number: Volume 7, Number 98