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

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

From news  Tue Oct 28 12:16:57 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix Volume 8
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 18:16:37 GMT
Draft-9: mod.std.unix

This is the first article in Volume 8 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 7.
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 8, Number 1

From news  Tue Oct 28 12:19:37 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix and P1003
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 18:19:24 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 (P.055)
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 8, Number 2

From news  Tue Oct 28 12:25:37 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: extern identifier length
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 18:25:16 GMT
Draft-9: 8.0

From: harvard!encore!vaxine!nw (Neil Webber)
Date: Tue, 28 Oct 86 09:52:37 est

> 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.
>
While I'm 100% behind this idea, I have to ask the question "how did this
come to be?"  As I recall, the major argument against providing longer
extern names in X3J11 was that it would preclude X3J11 conforming C
implementations on systems with restricted object file formats.  Is it
now impossible to provide a POSIX conforming implementation on those
systems?

This is only a problem for implementations layered on top of an existing
OS.  Being somewhat of a "young one", I haven't worked on any systems
with a 6-character extern limit.  (Life is tough, isn't it?) However, I'd
be interested in knowing what systems suffer from this restriction, and
why it doesn't matter that a POSIX environment can't be provided under
those systems.

Neil Webber     Automatix Inc.          Billerica MA
        {decvax,ihnp4,allegra}!encore!vaxine!nw

Volume-Number: Volume 8, Number 3

From news  Tue Oct 28 12:30:34 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: missing features from POSIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 18:30:15 GMT
Draft-9: 1003.2.getopt 1003.2.popen

From: pyramid!amdahl![e-mail] (Hal Jespersen)
Date: Tue, 28 Oct 86 06:59:26 PST
Organization: Amdahl Corp, UTS Products Group

In article <[e-mail]>:
 >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?
 >
 >Some of these functions were explicitly created to enhance portability,
 >so it seems surprising to omit them.
 >
 >getopt...
 >
This is actively being addressed in the 1003.2 Shell and Utilities
Working Group.

 >curses...
 >
This is not being addressed by 1003.2, as we are purposely avoiding
terminal interfaces and concentrating on shell interfaces from application
programs, such as through...

 >popen...
 >
which _is_ being included in 1003.2.

Volume-Number: Volume 8, Number 4

From news  Tue Oct 28 12:34:26 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  X3 display committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 18:34:11 GMT
Draft-9: X3H3.6

From: ulowell![e-mail]
Date: Tue, 28 Oct 86 12:58:07 EST

Actually the committee is not developing a model based on any window
system but is building a model that will support current and future
window management system.  Sun, DEC/MIT (Project Athena = X), Microsoft,
Apollo and many other window supporters/developers/implementors are actively
participating on X3H3.6;  we would greatly appreciate more help and
participation as this is a sizeable task.

Georges Grinstein
Director Graphics Research Lab

( Chair X3H3.6 )

Volume-Number: Volume 8, Number 5

From news  Tue Oct 28 13:08:21 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Oct 86 19:08:02 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
X3H3.6 (display committee)
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.

Machine readable copies of the Trial Use Standard are not and will
not be available.  A machine-readable "representation" of a draft
between the Trial Use and Full Use Standards may be available when
it is ready (probably in 1987).

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 P1003.1 working group are

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)

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)

Inquiries regarding 1003.2 and 1003.3 should go to the same address
as for 1003.1.

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

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

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

    groups of utility programs, or commands,

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

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

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.


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 /usr/group working groups as taken from
the CommUNIXations article mentioned above.  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 X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

    Georges Grinstein
    wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

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

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

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

A contact for information regarding publications and working groups is

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

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 8, Number 6

From news  Tue Oct 28 16:38:44 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 22:38:17 GMT
Draft-9: 1003.2.getopt

From: [e-mail] (Bennet Yee)
Date: Tue, 28 Oct 1986 14:17-EDT

There is nothing wrong with the old standby of "./-file" -- why all the
fuss with special-casing in getopt or "--file"?

-Bsy

--
Bennet Yee                            ~   ~
                                O   =
[e-mail]        (Arpa)                  ^
...!seismo!f.gp.cs.cmu.edu!byee    (Uucp)                \___/

Volume-Number: Volume 8, Number 7

From news  Thu Oct 30 18:57:15 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: 31 Oct 86 00:56:52 GMT
Draft-9: 1003.2.getopt

From: [e-mail] (Guy Harris)
Date: Tue, 28 Oct 86 23:20:53 PST

> >                                Since this one has
> >already been implemented by many commands, it is preferable.

> ...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 saw no great advantage offered by the proposed scheme.  It was more
"different" than it was "better".  I'll complete the thought, then: "Since
this one has already been implemented by many commands, since it requires less
reprogramming than changing all commands that accept flag arguments to
special-case arguments beginning with "--", and since it would be a novelty
to more users than the "'--' quotes a '-'" convention would be, it is
preferable."

> I say my suggestion is cleaner and more versatile, thus it is preferable.

I don't see how it is any "cleaner" than "--", although this depends on what
"cleaner" means.  It is slightly more versatile, in that it is not
context-dependent; however, this is not sufficient to make it preferable.
The cost of changing existing programs to use the "'--' quotes a '-'"
convention that is greater than the cost to changing them to use the
"getopt" convention.

> The required reprogramming would not be that complicated--just a minor
> nuisance.

No, it is not necessarily *complicated*, but that doesn't render it merely a
"minor nuisance".  It requires that all *non*-flag arguments be treated
specially.  Programs that accept flag arguments already treat them
specially.  Those that use "getopt" need not change at all.  Those that do
not can either be converted to use "getopt", or just be converted to
recognize a flag of the form "--" as an indication that no subsequent
arguments be treated as flag arguments.

> But if you wish appeals to history, ...

I *don't* want appeals to history; my comment was an appeal to existing
practice, and more specifically existing practice in the area of command
argument parsing.

Volume-Number: Volume 8, Number 8

From news  Thu Oct 30 19:21:42 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: problem with the iocntl proposal
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 31 Oct 86 01:21:25 GMT
Draft-9: 7.0

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: 28 Oct 86 03:12:38 GMT
Organization: AT&T Bell Laboratories, Columbus, Oh

The iocntl proposal, as stated in section C.3 of the POSIX book,
has a bug.  For those who don't have the book handy, it defines
    iocntl(fildes, command, mask, argp, argpsize)
where command specifies the unique name of the control; mask is
either IO_READ, IO_WRITE, or IO_READ|IO_WRITE; argp is a pointer
to the argument, and argpsize is the number of bytes in the argument.

It proposes implementation of upward compatibility
with ioctl with a define such as
    #define ioctl(a, b, c) iocntl(a, b, c, sizeof(c))
and using a two ident define for b, thus
    #define IO_READ        1
    #define IO_WRITE    2
    #define TERM_MASK    ('T'<<8)
    #define SOME_MASK    (IO_READ|IO_WRITE),(TERM_MASK | 0)
    ...
    struct foo *ptr = ...
    ioctl(0, SOME_MASK,ptr);

The bug here is that the sizeof is taken on the pointer, not the
item itself, so it will always be 4 on a typical 32 bit machine.

One obvious fix might change the spec to read
    #define ioctl(a, b, c) iocntl(a, b, c, sizeof(*c))
This might work for many cases.  But there are two cases for
which it fails:

(1) ioctls where the object pointed to is an array.  In particular
    if the argument is a character string, as in SVr3's I_PUSH ioctl
    to push a streams module, this won't work.
(2) ioctls where the argument value itself, rather than what's at
    the end of a pointer, is passed.  System V does this a lot;
    see, for example, TCSBRK, TCXONC, and TCFLSH.

One possible solution to this problem would be to rearrange the
order of the arguments to iocntl.  If it becomes

    iocntl(fildes, command, mask, argpsize, argp)

then a trick similar to the one used in 4.2BSD becomes possible:

    #define ioctl iocntl
    #define IO_READ        1
    #define IO_WRITE    2
    #define TERM_MASK ('T'<<8)
    #define SOME_MASK (IO_READ|IO_WRITE),(TERM_MASK | 0),sizeof (struct foo)
    ...
    struct foo *ptr = ...
    ioctl(0, SOME_MASK, ptr);

Another possibility is similar, but closer to what 4.2 does.  We
define iocntl as a function that takes three parameters, just like
ioctl, but the second parameter is a long, and we get

    iocntl(fildes, (long) command, argp)

    #define ioctl iocntl
    #define IO_READ        (1<<14)
    #define IO_WRITE    (2<<14)
    #define TERM_MASK ('T'<<24)
    #define SOME_MASK (long) (IO_READ|IO_WRITE)|(TERM_MASK | 0)|sizeof (struct foo)
    ...
    struct foo *ptr = ...
    ioctl(0, SOME_MASK, ptr);

As I understand it, the only reason for playing these games, instead of
just doing what 4.2 did and leaving it called ioctl, is that ioctl is
defined to take an int as the 2nd parameter, and this method has to pass
a long.  It works on a 32 bit machine, but not on a 16 bit CPU such as
an 80286 (unless you implement "int" as 32 bits.)  Am I missing something?

These comments apply to termcntl as well as iocntl.

By the way, if this proposal is going to be used, please let's change
the name from iocntl to something that doesn't *sound* the same as
ioctl.  Otherwise there will be lots of confusion.

    Mark

Volume-Number: Volume 8, Number 9

From news  Thu Oct 30 19:26:13 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]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Keywords: horrible
Date: 31 Oct 86 01:25:37 GMT
Draft-9: job.control

From: seismo!mcvax!jack
Organization: AMOEBA project, CWI, Amsterdam
Last-Band-Seen: Eton Crop, That Petrol Emotion (Paradiso, 30-09).
Opinion-Of-Them: Two good and honest guitar bands....
Date: Tue, 28 Oct 86 23:39:03 +0100

I waited for some time, thinking someone else would point this out,
but nobody did, so here goes:

*CURRENT JOB CONTROL IMPLEMENTATIONS ARE HORRIBLE. HORRIBLE!
HORRIBLE!!!!!!!!*

After reading David Lennart's (sp?) article on 4.2 job control,
SYSV shell layers, and HP-UX's hybrid I was shocked, I must admit.

Both solutions are filled with horrible tricks like closing
tty's and re-opening them and then doing funny ioctl()s and the closing
them again and then reopening then and then...

It is of course a praiseworthy feat that the folks at HP managed to
sqeeze those two horrible, inconsistent, unintellegible mechanisms
into one poor kernel, but I'm afraid the result is horrible**2.

I think that, if nobody can come up with a nice&clean subset of
job control facilities, that will allow sysV and BSD semantics to
be implemented on top of them, we should forget about standardising
anything. Standardising bad mechanisms will only hinder progress
(Did I hear someone say F77? X25?).

>From now on, you can find me in the "job control is horrible" camp.
--
    Jack Jansen, [e-mail]
    The shell is my oyster.


Volume-Number: Volume 8, Number 10

From news  Thu Oct 30 19:39:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: file times and shell commands
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 31 Oct 86 01:39:06 GMT
Draft-9: 1003.2.newer

From: [e-mail]  (Jim Mayer)
Date: Wed, 29 Oct 86 22:15:54 est

I have two suggestions that fall into the "new feature" category.  The
first concerns file time manipulation from the shell.  The second
follows from the first, and concerns the combining power of the Bourne shell.

There doesn't appear to be any decent way to compare the last modified
times of files from the shell.  I have written programs to do this,
but that makes any scripts I write using the programs essentially
unexportable.

There are several approaches to fixing the problem:

1. Extend the "test" command, perhaps by borrowing the "-newer" syntax
   of "find".
2. Add a new command.  One possibility is
    "isconsistent file other-files..."
   which would return true if the first file was created after all of
   the "other-files".
3. Resign oneself to writing:
    if [ `ls -t a b | head -1` = a ]
    then echo "a was done later than b"
    fi

All three work, however the second points out a problem with the
Bourne shell: there is no "not" operator!

If an "isconsistent" command was implemented, then to write code that
(for example) recompiled a C file if the object file was out of date,
one would have to write:

    if isconsistent fu.o fu.c
    then true
    else cc -c fu.c
    fi

instead of

    if ! isconsistent fu.o fu.c
    then cc -c fu.c
    fi

Of course, one could always add an "isinconsistent" command, but that
avoids the point.  A "not" command that ran the command specified by
its arguments and inverted the exit code would be better, but would
still not handle things like "if ! (test1 || test2)" easily (I suspose
we could all write in conjunctive normal form (ugh!)).  If there was a
"not" operator then the Bourne shell syntax would be powerful enough
to express arbitrary boolean forms.

That, of course, raises the possibility of getting rid of the "test"
command entierly and replacing it with lots of little "gt" and "eq"
commands.  But that's another story.... (and hardly a job for a
standards group!)

-- Jim Mayer                    Computer Science Department
(arpa) [e-mail]            University of Rochester
(uucp) rochester!mayer                Rochester, New York 14627


Volume-Number: Volume 8, Number 11

From news  Sat Nov  1 17:37:46 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]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 1 Nov 86 23:37:33 GMT
Draft-9: job.control

From: pyramid!nsc!hplabs!hpda!hpisoa1!davel (Dave Lennert)
Date: Wed, 29 Oct 86 10:07:47 -0800

> From: seismo!munnari!yabbie.rmit.oz![e-mail] (Ian Donaldson)
> Date: Tue, 21 Oct 86 10:39:40 EST
>
> What is the significance of the "saved process group ID"?  How is
> it different to the normal process-group-ID?  Who uses it?

The saved process group ID is analogous to the saved user and group ID's
in System V.  They preserve the original values the process had when
exec'd.  This allows the process to adopt a different value for one
of these ID's and later return to its original value.  Without a "saved"
value, all knowledge of the original value and of the process's rights
to use it are lost.

The saved process group ID value is necessary with job control in the
following scenario:

Root user su's to non-root user whose login shell is a job control shell
(say csh).  Csh resets its process group to a new value (it becomes a
process group leader).  When it terminates or suspends, it needs to
restore both the tty group ID (a process group ID value) and its own
process group ID back to the original values they had at entry.  (This
restores its parent to the foreground.)  Under 4.2 this is no problem
since there are no security checks for this.  Under POSIX there are
security checks based on uid's which normally are allowed since the uid of
the parent process and the csh are identical, but in our scenario would
be disallowed because the uid's don't match.  The saved process group ID
is an alternate security check which allows the above scenario.  See the
security discussion in setpgrp2() and in the POSIX termios proposal.

> >          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;

"May" is used here to allow 4.2 systems to conform.  4.2 does not
send SIGHUP on process group leader death.

Note that, with a job control shell, all child processes started by
the shell are placed in a different process group than the (process
group leader) shell is in.  Thus when the shell dies, SIGHUP is not
seen by any of the children anyway.

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

This key feature is preserved in the POSIX specification.  Perhaps I
don't understand your statement.

> 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).
> I see no mention of a vhangup equivalent in this proposal segment, but
> then again, I haven't seen the whole of P1003 either.

vhangup() is indeed desirable.  It is not required in POSIX because it is
not supported on System V and, indeed, breaks System V compatiblity.
(See my job control paper that was posted in mod.std.unix recently.)

> Children of init that are stopped are also sent SIGHUP's and SIGCONT's.

More correctly, at the time a stopped process is inherited by init (due
to its parent's death), it is sent SIGHUP and SIGCONT.  POSIX has this
too; see the _exit part of the job control specification.

> Infinite-loop processes don't cause problems with system-response because
> they are automatically niced (something that is long-needed in UNIX systems).

Note that this is NOT desirable on, e.g., realtime systems where that
long running process may be critical.  I'm also getting tired of having
my rwhod reniced automatically.

    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]


Volume-Number: Volume 8, Number 12

From news  Sat Nov  1 17:41:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: The POSIX file system
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 1 Nov 86 23:40:50 GMT
Draft-9: 2.3.folding

From: [e-mail] (Rick Genter)
Date: 30 Oct 86 09:57:13 EST (Thu)

Here's the text of my original article, modified to reflect dmr's comments:

     The recent discussion regarding the issue of case insensitivity in the
POSIX environment has caused me to think about the Unix file system and
its impact on the kernel.  I came into the Unix game late, but as I understand
it, various flavors of Unix (such as MERT, Unix' real-time cousin),
implemented the file system completely outside the kernel, I suppose as a
library of routines.  I also understand that the MACH project at CMU is
heading in this direction.

     The primary reason that I see for having the file system in the kernel in
the first place is perhaps for efficiency and to solve certain concurrency
problems.  I see making the file system case insensitive as another step in
this direction; unfortunately I see it as a step backwards.  I suppose the
next logical step would be to put wildcard expansion in the kernel.

     If any sort of fundamental change is to be made to the file system for
POSIX, I'd prefer moving towards a non-kernel file system.  In addition to
simplifying the design of the operating system, it also allows users to
implement layers on top of the file system, such as case insensitivity,
wildcard expansion, network file systems, access methods, etc.  Gee, is this
starting to sound like streams?

     Personally, I'd rather that POSIX not change the appearance of the Unix
file system; it's too big a task to do right involving a redesign rather
than a standardization.  This is clearly (at least to me) outside the scope
of an effort such as P1003.
--------
Rick Genter                 BBN Laboratories Inc.
[phone]                10 Moulton St.  6/512
[e-mail]  (Internet new)    Cambridge, MA   02238
[e-mail] (Internet old)    seismo!bbncca!rgenter (UUCP)

Volume-Number: Volume 8, Number 13

From news  Sat Nov  1 17:59:06 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]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 1 Nov 86 23:58:55 GMT
Draft-9: 2.3.folding

From: nike!oliveb!3comvax!marcl (Marc Lavine at 3Com Corporation)
Organization: 3Com Corp., Santa Clara, CA
Date: Thu, 30 Oct 86 21:34:05 PST

In article <[e-mail]> you write:
>From: seismo!mcvax!guido (Guido van Rossum)
>(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!)

In case you weren't aware, PC-DOS also has a mechanism for changing
the date and time display formats based on what country you are in.
You can set the country by using a statement such as country = 031
(for the Netherlands) in the config.sys file.  DOS will use this
information when displaying dates and times (such as in directory
listings) and it is also available to application programs that want
to use it.  This has better support in DOS versions 3.0 and later than
in DOS 2.1.
--
Marc Lavine
UUCP:        ...{ihnp4|nike|hplabs|sun|glacier}!oliveb!3comvax!marcl

Volume-Number: Volume 8, Number 14

From news  Sat Nov  1 18:13:44 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: 2 Nov 86 00:13:29 GMT
Draft-9: job.control

From: seismo!vrdxhq!inteloa!omepd!jimv (Jim Valerio)
Organization: Intel Corp. Hillsboro, Oregon
Date: Wed, 08 Oct 86 14:59:16 -0800

I object to one claim made by Henry Spencer on job suspension:
>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.

Completely independent of terminal interfaces, job suspension is a
useful feature.  In particular, I have a batch queue mechanism in
mind on 4.2bsd UNIX which suspends batch jobs when the interactive
load gets too high, and restarts them (sending SIGCONT) when
the interactive load drops again.  This control can be done both
by an operator and by a daemon, and has no notion of controlling
terminal for the batch job.

As Henry indicates, job suspension and multi-process control are
two different items.  Even though job control may not be the only
or best way to implement multi-process control, job suspension is
an important feature in its own right.
--
Jim Valerio    ogcvax!inteloa!omepd!jimv, tektronix!psu-cs!omepd!jimv

Volume-Number: Volume 8, Number 15

From news  Sat Nov  1 18:17:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: file times and shell commands
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 2 Nov 86 00:17:15 GMT
Draft-9: 1003.2.newer

From: pyramid!utzoo!henry (Henry Spencer)
Date: Fri, 31 Oct 86 21:25:31 CST

> There doesn't appear to be any decent way to compare the last modified
> times of files from the shell...

Before everybody starts inventing their own names for this, it should be
noted that V8 already has a program for this, newer(1).  It takes two
filenames as arguments, and exits with status 0 if and only if either
(a) the first exists and the second does not, or (b) both exist and the
first's modification time is at least as recent as the second's.  Other-
wise it exits with non-zero status.  (The preceding two sentences are
essentially the whole of the manual page for it.)

Relatively few people have V8, but in the absence of any other precedent
for what this facility should like look, it seems reasonable to follow
V8's lead.

Here is an independent rewrite, done from the manual page and not the
code, by me, hereby placed in the public domain:

/*
 * newer - is first file newer than second?
 */

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

main(argc, argv)
int argc;
char *argv[];
{
    struct stat file1;
    struct stat file2;

    if (argc != 3) {
        fprintf(stderr, "Usage: %s file1 file2\n", argv[0]);
        exit(2);
    }

    if (stat(argv[1], &file1) < 0)
        exit(1);
    if (stat(argv[2], &file2) < 0)
        exit(0);
    if (file1.st_mtime >= file2.st_mtime)
        exit(0);
    exit(1);
}

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

Volume-Number: Volume 8, Number 16

From news  Sat Nov  1 18:24:54 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: 2 Nov 86 00:24:43 GMT
Draft-9: 1003.2.getopt

From: seismo!unido!exunido!hmm (Hans-Martin Mosner)
Date: Sat, 1 Nov 86 03:10:54 +0100

One problem with all the methods for escaping -file is that wildcard expansion
by the shell will still get the real names.  So if I happen to have a file
"-rf" in my home directory and do a "rm *f", I'm out of luck :-)
I have no solution for this, though...

    Hans-Martin Mosner
    University of Dortmund (W. Germany)

Volume-Number: Volume 8, Number 17

From news  Sun Nov  2 10:57: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]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 2 Nov 86 16:57:37 GMT
Draft-9: 2.3.folding

From: seismo!enea!chalmers.UUCP!jacob (Jacob Hallen)
Date: Sun, 2 Nov 86 01:38:02 -0100
Organization: Dept. of CS, Chalmers, Sweden

I would like to point out one small but very useful advantage with
case sensitive filenames.
In a directory containing many files its difficult to spot files
with names like makefile, readme and instructions. Given the names
Makefile, Readme and Instructions these files will appear first
in the listing where they are easy to find.

Jacob Hallen

Volume-Number: Volume 8, Number 18

From news  Mon Nov  3 13:33:07 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: 3 Nov 86 19:32:55 GMT
Draft-9: 2.3.folding

From: [e-mail] (Guy Harris)
Date: Mon, 3 Nov 86 00:54:24 PST

> I would like to point out one small but very useful advantage with
> case sensitive filenames.
> In a directory containing many files its difficult to spot files
> with names like makefile, readme and instructions. Given the names
> Makefile, Readme and Instructions these files will appear first
> in the listing where they are easy to find.

This is an advantage of file systems that permit both upper-case and
lower-case letters in file names.  File systems with case-sensitive file
names, and file systems with case-insensitive file names, can both permit
two cases of letters in file names.

[ Perhaps the third kind is called case-coercing? -mod ]

Volume-Number: Volume 8, Number 19

From news  Mon Nov  3 13:34:47 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 19:34:33 GMT
Draft-9: job.control

From: [e-mail] (Guy Harris)
Date: Mon, 3 Nov 86 00:39:00 PST

> > >          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;

> "May" is used here to allow 4.2 systems to conform.  4.2 does not
> send SIGHUP on process group leader death.

4.2 also doesn't have the notion of a "session process group leader".
However, when the moral equivalent of a "session process group leader" dies
in 4.2, 99.99% of the time it's a login shell, and "init" proceeds to do a
"vhangup" which - sends a SIGHUP!

> vhangup() is indeed desirable.  It is not required in POSIX because it is
> not supported on System V and, indeed, breaks System V compatiblity.

Only if you define "System V compatibility" as "behaves exactly the same as
some particular implementation of System V".  "vhangup" does two things; it
sends a SIGHUP to the process group of the terminal in question (which is,
in fact, similar to what S5 does automatically) and it invalidates file
descriptors that refer to the terminal.

Some System V implementations do not do this, although they *do* clear the
terminal's process group, which causes all subsequent references to that
terminal through "/dev/tty" to get an error.  As such, the evidence
indicates that the reason they don't generally invalidate references to the
controlling terminal is *not* that they intended to leave such references
valid, but that they just didn't bother.

The only programs *I* can think of that would want to be able to reference
the terminal they were started from, even after the user who started them
logged out, are not the sort of programs I would like to have running on any
machine I'm involved with.  They tend to be called things like "Trojan
horses".

Volume-Number: Volume 8, Number 20

From news  Mon Nov  3 13:35:46 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: The POSIX file system
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 19:35:34 GMT
Draft-9: 2.3.folding

From: [e-mail] (Guy Harris)
Date: Mon, 3 Nov 86 00:50:03 PST

> I came into the Unix game late, but as I understand it, various flavors
> of Unix (such as MERT, Unix' real-time cousin), implemented the file system
> completely outside the kernel, I suppose as a library of routines.

Yes, and no.  They did implement it outside the kernel, although not in user
mode.  The file system was implemented by a process that ran in supervisor
mode and which received messages telling it to do things like read from or
write to a file.  Other operating systems, like RSX-11 and VMS, did the same
thing.  I believe the latest descendents of MERT, and VMS, have moved the
file system back into the kernel for performance reasons.

>      If any sort of fundamental change is to be made to the file system for
> POSIX, I'd prefer moving towards a non-kernel file system.  In addition to
> simplifying the design of the operating system, it also allows users to
> implement layers on top of the file system, such as case insensitivity,
> wildcard expansion, network file systems, access methods, etc.  Gee, is this
> starting to sound like streams?

POSIX does not specify whether the file system is implemented in the kernel
or not.  Even if a particular POSIX implementation has the file system in
the kernel, it can implement things like "case insensitivity, wildcard
expansion, network file systems, access methods", etc. on top of the file
system.  One system that is nearly POSIX-compatible, called the UNIX system,
has done the last three of these (wildcard expansion in the shell - this
could also be made into a user-mode library; network file systems, such as
the Newcastle Connection and IBIS, implemented as user-mode wrappers around
calls like "open", "read", "write", etc.; access methods such as C-ISAM,
that are just user-mode libraries).

Remember, POSIX is an *interface* specification, not an implementation.  The
fact that many (most?)  POSIX implementations, including the UNIX
implementation, will have the file system in the kernel says nothing about
POSIX.

Volume-Number: Volume 8, Number 21

From news  Mon Nov  3 13:39:27 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]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 19:39:15 GMT
Draft-9: 2.3.folding

From: [e-mail] (Guy Harris)
Date: Mon, 3 Nov 86 00:51:47 PST

> In case you weren't aware, PC-DOS also has a mechanism for changing
> the date and time display formats based on what country you are in.
> You can set the country by using a statement such as country = 031
> (for the Netherlands) in the config.sys file.

Yes.  Note, however, that this still doesn't do anything about the limited
character set permitted for MS-DOS files, so it seems you're stuck if you
want to give a file a name that includes characters not in the regular ASCII
set (or even some characters *in* the regular ASCII set).

Volume-Number: Volume 8, Number 22

From news  Mon Nov  3 13:59:44 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: editorial policy for mod.std.unix
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 19:59:31 GMT
Draft-9: mod.std.unix

A few weeks ago I promised a statement on editorial policy.  This is it.

I see the purpose of being the moderator of mod.std.unix as being to keep
the signal to noise ratio high, and I see five primary ways of doing this:

1) eliminating duplicate information
2) discouraging other noise
3) correcting factual errors
4) spelling correction and other production work
5) encouraging diversity

Lately I've tried to accomplish these by

1) rejections
2) rejections and editorial comments
3) editorial comments and occasional rejections
4) direct textual correction and extra articles (such as this one)
5) articles introducing new subjects


More comments on some of these methods later in this article, but
first what happens to an article I receive for submission:

If it is rejected (about ten per cent are), I mail a reply either
explaining why or suggesting a better place to submit it (or, often,
both).  Sometimes this results in cycles of correspondence and even
sometimes in other articles by the same submittor that are posted.
This is desirable, but a rejection is almost always more work than
an acceptance, often much more.

The most common reason for rejection is duplication of information:
in that case I mail a reply pointing out something to the effect that
"what you wrote has already been remarked on by x and y in articles
that arrived after the one you're following up to:  do you still want
yours posted?"


If an article is approved, it is posted exactly as submitted with
the following possible exceptions:

    Some header lines of the posted article, such as Subject:,
    References, Keywords:, and Summary: are derived from header
    lines of the submission, such as Subject:, References:,
    In-Reply-To:, Keywords:, and Summary:.  Information from
    other header lines of the submission, such as From:, Date:,
    and Organization:, are preserved in the first few lines of
    the text of the posted article (the submittor's real name,
    if it can be found readily, is included in the From: line).

    Preliminary comments of the submittor that are addressed
    directly to the moderator (such as "submit this if you
    think it is appropriate") are removed.

    A Volume-Number: line is appended to the posted article.

    Readily apparent spelling errors (their vs. there, its
    vs. it's, here vs. hear, etc.) are corrected.  Network
    addresses (as found in signatures) that clearly will not
    work (such as [e-mail]) are fixed, when known.
    Long or irrelevant signature lines are elided.

    Finally, comments by the moderator may be interspersed.
    They are always clearly marked.  [ Like this.  -mod ]

Other than as noted here, nothing is added to and nothing is deleted
from a submitted article when it is posted.

I've received a number of submissions that say something to the
effect of "post what parts of this you think appropriate."
Sorry, I don't do that.  I don't have time or inclination to edit for
content (just interspersing comments now and then takes a noticeable
amount of time), and the only way I could plausibly do it anyway would
be to edit an article and send it back to the submittor for approval
before posting.  The few times I've tried this have been dismal
failures due to the slow delivery speeds and high failure rate of the
UUCP mail network in addition to the amount of editing time involved.


Now, a few more involved comments, working more or less backwards.

I've gotten several letters lately regarding interspersed comments
by the moderator in recent articles (three for, two against).
One, which interpreted the interspersed comments as the moderator
taking sides, pointed out that that should be done in personally
signed (i.e., not signed by the moderator) followup articles.
In fact, that is my usual practice when I do take sides, as seen
in previous volumes of mod.std.unix.

Recent interspersed comments by the moderator have been for three
purposes:  to recapitulate information that the submittor doesn't seem
to have noticed but which nonetheless has been brought up at length by
other posters (this is to keep the other posters from having to say it
all again);  to correct factual errors (so other posters don't have to
do it); and to discourage ad hominem attacks and other irrelevant
rhetorical techniques that lead only to more noise and less technical
content.  Some have mistaken the last two of these for taking sides in
argument.  Those who have done so should examine the recent volume and
notice the lack of correlation between the side of the case sensitive
file name argument and article is on and the number of interspersed
comments by the moderator.


There has been a spate of submissions recently involving ad hominem
attacks (name calling, if you will) on opponents named or unnamed.
Those using personal names have been rejected.  Those not doing so have
been posted with comments by the moderator discouraging the practice.
Experience indicates to me that the former approach works better.  From
now on I will reject any article containing personal attacks on anyone
(or any group) named or unnamed, regardless of the content or lack
thereof of the rest of the article.  (If this happens to you, you can
always edit it yourself and resubmit it.)

It is evidently necessary to point out that there is a difference
between attacking an argument and attacking the person who made it.
It is ok to say an argument is "utterly loony."  It is not ok to
say someone who made an argument is "utterly loony" (or a cretin,
an idiot, lazy, etc.).

Why not?  Because such verbiage is irrelevant to a technical discussion
and will only cause the someone to at least be offended and probably
to followup with equally irrelevant verbiage, thus reducing the
technical content of the newsgroup not once but twice or many times.
It is probably unnecessary to point out that derogatory and untechnical
verbiage even applying to arguments should be used sparingly, if at all.

Why do I care?  Because I still suffer through reading net.unix
and net.unix-wizards and I don't want this newsgroup to descend
to that level.


By the way, remember that I don't get paid for moderating.  It takes
less time than some have thought (due to use of a really baroque
shell script), but that time is still taken from other things I'm
trying to do (like earn a living).

Finally, remember that the networks are flaky (and I've even been
known to manage to lose articles):  if you submit something and don't
see it in the newsgroup or get a reply in a week or two, it's probably
worth resubmitting it.

Moderator, John S. Quarterman

Volume-Number: Volume 8, Number 23

From news  Mon Nov  3 14:05:40 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Job Control and Window Sizes: a common ground solution
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 20:05:27 GMT
Draft-9: job.control

From: [e-mail] (David Janes)
Date: Sun, 2 Nov 86 11:29:02 pst

The tty driver should provide a character i/o interface to the outside
world, and nothing else.

SIGWINCH, SIGSTOP, SIGCONT, etc. all have a similar purpose: to
inform the user process that there has been a change in the `environment'
that the process is using. (The real purpose of SIGCONT, besides
putting a process back in run queue, is to inform a process that its
output screen has been dirtied.) In addition to signals, ioctls have been
added to ask the tty driver about it's environment: how big is my screen,
and so on.  All these are currently implemented as tty driver `aids', and
really have no place there.

The Solution: an `environment' file should be available for
every tty device (including pseudo-ttys.)
All changes to the tty's environment are reflected into this
file. If the window size is changed (by whatever), the window
size part of that file is modified. If the screen is `dirtied',
a `dirty screen' flag is set, and so on.

The environment file is a normal UNIX file. Some programs like init,
and so on may need to be modified to keep this file with the
right protections and so on, but this is basically minor.

Processes (including the kernel for some implementations) which change
the environment of the tty merely update this file when they
make those changes.

One kernel change must be added. A SIGIO signal should be
sent when this file is modified to all interested processes (who
declare the interest via `fnctl' or some similar mechanism.)
This change can be justified outside the concept of `environments'
as a reasonable extension to the SIGIO facility.

The stopping and restarting of processes can be implemented
sensibly and independantly of this scheme.

NOTES:
[1]    this could be added to system V to make job control as `nice'
    to the user as Berkeley job control, and still be entirely backwards
    compatable.

[2]    window management process (even if implemented in the kernel)
    simply write their changes to the environment file if
    the screen size gets changed.

[3]    simple window management, which doesn't redraw screens,
    can be implemented under the same scheme. Thus, many styles
    of `job control' (in the broad sense) may be implemented.

dave
--
.o.o.  The             UUCP: {utcsri,ihnp4,allegra,philabs}!garfield!dave
.:O:.  Mercenary     CDNNET: David Janes <[e-mail]>
.o.o.  Programmer    "There can only be one!"

Volume-Number: Volume 8, Number 24

From news  Mon Nov  3 14:10:37 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: 3 Nov 86 20:10:17 GMT
Draft-9: 2.3.folding

From: @SUMEX-AIM.ARPA:MRC@PANDA (Mark Crispin)
Date: Sun 2 Nov 86 10:54:35-PST
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: [phone]

Jacob Hallen -

     You missed the point, I think.  Very few if any of us in the
case-independence camp are arguing that case should be coerced into
all upper (e.g. TOPS-20) or all lower (e.g. what you have to do with
a Unix file server in a case-independent network environment).  You
should be allowed to create a file called ReadMe.

     What we are asking for is that if you try to access the ReadMe
file by specifying "readme" or "Readme" or "README" or even "rEADmE"
you should get the ReadMe file instead of a file not found error.
Furthermore, if you open "readme", "Readme", etc. for write, it should
supercede the ReadMe file and the resulting file should have the
original case of ReadMe.

     In other words, finding a file for read will match any case.
Finding a file for write will match any case, supercede any such older
file, and will preserve the case of that older file.  The only way to
change the case would be with rename; the source name would be case
independent but the destination case would be preserved.  Of course,
you could also change the case by deleting ReadMe and then opening
README for write...

     This gives you all the directory advantages of a case-dependent
filesystem.  The only "feature" you lose is the ability to create a
separate Readme, ReadMe, readme, and README set of files.  I personally
believe that anybody who creates files which differ from case deserves
to be shot or at least have his employment terminated with extreme
prejudice.  [ I suggest readers interpret that last sentence as a
hypothetical statement applying to none of them.  -mod ]

     There are filesystems that behave in this manner, and they are
quite pleasant to use.  Please, if you support case-dependence, don't
give the "mixed case filesystems" class of arguments.  The only two
arguments you really have are (1) it is a "feature" (however dubious)
that you can create Makefile and makefile as separate files in the
same directory, and (2) Unix does it this way.
-------

Volume-Number: Volume 8, Number 25

From news  Mon Nov  3 14:12:24 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: case sensitive filenames
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 20:12:11 GMT
Draft-9: 2.3.folding

From: seismo!utai!utcsri!mcgill-vision!mouse
Date: Thu, 30 Oct 86 05:28:02 EST

In article <[e-mail]> [e-mail] (Paul E. McKenney) writes:
[that what he said above leaves unaddressed]
> 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!).

There are also programs (the shell comes to mind) that use the eighth
bit for their own purposes.  I believe the shell uses it as a quote
indicator.  Although it is not relevant to filenames, I seem to recall
seeing some code along the lines of curses that used the eighth bit to
indicate highlighting.  Also, all the 7-bit characters can be specified
to (say) rm by careful use of quotes or backslashes.  With most
terminals, this is not possible for 8th-bit-set characters, and even if
the terminal and tty driver could handle it, as I implied above the
shell would strip it anyway.  So you *couldn't* do anything with such
files.

                    der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision![e-mail]

Volume-Number: Volume 8, Number 26

From news  Mon Nov  3 14:14:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: A convention for -file
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 3 Nov 86 20:14:39 GMT
Draft-9: 1003.2.getopt

[ I'm not positive anything in this article has not been said before,
but it's a useful summary.  -mod ]

From: nike!pyramid!pyrtech!trwrb!desint!geoff (Geoff Kuenning)
Date: Wed, 29 Oct 86 01:02:04 pst
Organization: SAH Consulting, Manhattan Beach, CA

In article <[e-mail]> [e-mail] (Matthew P Wiener)
writes:

> 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

There're at least two reasons not to do this:  (1) it's unnecessary, and
(2) it conflicts with the standard already established for getopt(3).

It's unnecessary because you can *always* specify a file beginning with
"-" as "./-file".  I find this much easier to remember.

The second reason is that getopt(3) already explicitly defines an argument
of "--" as delimiting the end of the switches.  It is provided specifically
to handle the case when an argument begins with a dash.

Thus, for example, to grep(1) for commands that take a "-i" switch, we
would use:

    egrep -- -i /usr/man/u_man/man1/*

(Note that this applies only on System V;  BSD uses an older convention.
Also note that some System V documentation incorrectly lists the obsolete
"-e" switch for this purpose;  "-e" doesn't work, but "--" does.)
--

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

Volume-Number: Volume 8, Number 27

From news  Mon Nov  3 18:56:58 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: missing routines
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Nov 86 00:56:45 GMT
Draft-9: 1003.2.getopt 1003.2.popen

From: [e-mail] (VLD/VMB) (Douglas A. Gwyn)
Date:     Mon, 3 Nov 86 11:31:40 EST

getopt() -- this would depend on adoption of the AT&T "command language
syntax standard", which is in the domain of 1003.2.  This may happen.

curses -- this lies outside the scope of X3J11 and 1003.1.  It would
perhaps be worth standardizing in some other 1003.n working group.

popen() -- this was discussed by X3J11 and excluded, on the grounds that
non-UNIX vendors would find themselves under pressure from customers
to make popen() useful rather than just a stub, and the inability to
do this would lead to unhappiness.  Similar arguments against system()
were somewhat weaker, and although its return value semantics were
reworked, system() survived since it is implementable in a non-trivial
way far more often than popen().

I don't know what problems Mark could have with <memory.h>, since
it isn't in the X3J11 draft proposed standard, nor with memccpy(),
which doesn't exist.  If he meant memcpy(), X3J11 permits SVID
semantics for that now.  (The previous "Rob Pike special" is also
defined, under the name memmove(), since there was no consensus for
preferring either of the two possible specifications for the function.
I suspect in many implementations memmove() and memcpy() will be
synonymous.)

P.S.  The X3J11 draft proposed standard intended for public review and
comment has been printed, but has to receive some sort of official
approval (X3?) before it is actually sent out to the public.  This
will take something like a month longer than originally anticipated,
as I understand it.  Patience!

Volume-Number: Volume 8, Number 28

From news  Mon Nov  3 19:34:36 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: public-domain implementation of V8 "newer"
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Nov 86 01:34:23 GMT
Draft-9: 1003.2.newer

From: [e-mail] (VLD/VMB) (Douglas A. Gwyn)
Date:     Mon, 3 Nov 86 10:37:13 EST

/*
    newer -- test file modification dates

    last edit:    86/03/30    D A Gwyn
*/
#ifndef lint
static char    SCCS_ID[] = "@(#)newer.c    1.1";
#endif

#include    <sys/types.h>
#include    <sys/stat.h>

#define    EXIT    _exit            /* non-STDIO exit(), if available */

#define    STDERR    2            /* standard error file descriptor */

extern void    EXIT();
extern int    stat(), write();

main( argc, argv )
    int            argc;
    char            *argv[];
    {
    static char        usage[] = "Usage: newer file1 file2\n";
    static struct stat    file1;    /* file1 statistics */
    static struct stat    file2;    /* file2 statistics */

    if ( argc != 3 )
        {            /* wrong number of arguments */
        (void)write( STDERR, usage, sizeof usage - 1 );
        EXIT( 3 );
        }

    if ( stat( argv[1], &file1 ) != 0 )
        EXIT( 2 );        /* file1 doesn't exist */

    if ( stat( argv[2], &file2 ) != 0 )
        EXIT( 0 );        /* file2 doesn't exist */

#ifdef lint
    return file1.st_mtime < file2.st_mtime ? 1 : 0;
#else
    EXIT( file1.st_mtime < file2.st_mtime ? 1 : 0 );
#endif
    }

Volume-Number: Volume 8, Number 29

From news  Mon Nov  3 19:37:06 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: extern identifier length
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Nov 86 01:36:54 GMT
Draft-9: 8.0

From: [e-mail] (VLD/VMB) (Douglas A. Gwyn)
Date:     Mon, 3 Nov 86 11:42:19 EST

Neil Webber asked why POSIX does not suffer from the constraint that
led X3J11 to reluctantly require only 6-character monocase extern
identifier uniqueness.  I think the basic answer is that POSIX is
intended to be a UNIX, or UNIX look-alike, interface standard, and
that "layered" implementations on top of other operating systems,
while not precluded by POSIX, are not specifically catered to.
Thus, a much narrower class of operating system linkers and object
module formats is involved, and it is felt that those few that don't
already support long extern identifiers can be changed to do so,
since the POSIX implementors on such systems are in a position to
accomplish this (unlike implementors of many layered systems).

Volume-Number: Volume 8, Number 30

From news  Mon Nov  3 19:38:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: The POSIX file system
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Nov 86 01:38:41 GMT
Draft-9: 2.3.folding

From: [e-mail] (Jeff Siegal)
Date: Mon, 3 Nov 86 17:44:44 EST
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA

In article <[e-mail]> [e-mail] (Guy Harris)
>[...]  The file system was implemented by a process that ran in supervisor
>mode and which received messages telling it to do things like read from or
>write to a file.  Other operating systems, like RSX-11 and VMS, did the same
>thing.  I believe the latest descendents of MERT, and VMS, have moved the
>file system back into the kernel for performance reasons.

Quite far off, actually (at least in the case of VMS).  Current
versions of VMS have replaced the disk filesystem ACP (which
previously was a separate process) with the XQP, a separate instance
of which exists in _each_process_ (the code is shared).  This resulted
in some significant performance _improvements_, and a filesystem which
extends fairly easily and quite completely (including record/file
locking, etc.) over different machines (using DEC's inter-system CI
bus).

Jeff Siegal

Volume-Number: Volume 8, Number 31

From news  Tue Nov  4 11:23:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: The POSIX file system
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Nov 86 17:22:50 GMT
Draft-9: 2.3.folding

From: [e-mail] (Garry Wiegand)
Date: Tue, 4 Nov 86 00:45:47 EST
Organization: Cornell Engineering && Flying Moose Graphics

In a recent article [e-mail] (Jeff Siegal) wrote:
>In article <[e-mail]> [e-mail] (Guy Harris)
>>[...]  I believe the latest descendents of MERT, and VMS, have moved the
>>file system back into the kernel for performance reasons.
>
>Quite far off, actually (at least in the case of VMS).  Current
>versions of VMS have replaced the disk filesystem ACP (which
>previously was a separate process) with the XQP, a separate instance
>of which exists in _each_process_ (the code is shared).  [...]

Sorry to quibble, but the original posting was accurate. There is now
a piece of the kernel which Dec has labelled the "XQP". The code runs
in the context of a user-process, as is indistinguishably true of every
other system service. The stated reason for making the move was increased
performance. That the cluster software was easier to write was probably
a bonus.

garry wiegand   ([e-mail])

Volume-Number: Volume 8, Number 32

From news  Tue Nov  4 11:28:35 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: file times and shell commands
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Nov 86 17:28:22 GMT
Draft-9: 1003.2.newer

From: [e-mail]  (Arnold D. Robbins)
Date: Mon, 3 Nov 86 13:20:48 EST
Organization: Math & Computer Science, Emory University, Atlanta

In article <[e-mail]>:
>From: [e-mail]  (Jim Mayer)
>Date: Wed, 29 Oct 86 22:15:54 est
>
>[....]
>
>There doesn't appear to be any decent way to compare the last modified
>times of files from the shell.  I have written programs to do this,
>but that makes any scripts I write using the programs essentially
>unexportable.
>
>There are several approaches to fixing the problem:
>
>1. Extend the "test" command, perhaps by borrowing the "-newer" syntax
>   of "find".
>[....]

The Korn shell did just this. In addition to the standard options listed
in the (System V) test(1) man page, there are four more options:

    -L    [ -L file ]; true if file is a symbolic link
    -nt    [ file1 -nt file2 ]; true if file1 is newer than file 2
    -ot    [ file1 -ot file2 ]; true if file1 is older than file 2
    -ef    [ file1 -ef file2 ]; true if file1 and file 2 same device/inode

The -L option will always be false on System V. The -ef goes through symbolic
links; you have to use [ f1 -ef f2 -a ! -L f1 -a ! -L f2 ] to be absolutely
sure.

>[....]
>All three work, however the second points out a problem with the
>Bourne shell: there is no "not" operator!

As has been pointed out in other forums, the S5 /bin/sh and the ksh both
support shell functions:

    not () {        # also "function not {" in ksh
        if "$@"
        then return 1
        else return 0
        fi
    }

    if not x y z a ...
    then
        whatever
    fi

Older /bin/sh versions leave you no choice:

    if x y z a ...
    then    :
    else
        whatever
    fi

A standard "not" operator would be nice, but shell functions and the test
stuff outlined above would be even better! (No, let's not start a debate
about shell functions vs. aliases vs. other shell features. We've already
been through that once on unix-wizards a while back.)
--
Arnold Robbins
CSNET:    arnold@emory    BITNET:    arnold@emoryu1
ARPA:    [e-mail]
UUCP:    { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold

Volume-Number: Volume 8, Number 33

From news  Tue Nov  4 11:36:36 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: 4 Nov 86 17:36:22 GMT
Draft-9: 2.3.folding

From: [e-mail] (Chris Torek)
Date: Tue, 4 Nov 86 07:33:44 EST

We seem to have three proposals:

CS: Case sensitive file systems.  This is what all major Unix variants
    (V6, V7, SysIII, SysV, 2BSD, and 4BSD) now support.

CC: Case coercive file systems (file names forced to all upper or all
    lower case).

CR: Case retaining but otherwise insensitive file systems (new names
    are created according to the given case; matches are not case
    sensitive).

I sincerely hope that no one is seriously suggesting POSIX adopt
CC: no one seems to like such systems much.  That leaves CS and
CR.  The case for CR appears to be that those who have used both
CS and CR prefer CR.  This may be true; I have seen no studies,
but the anecdotes do seem to favour it.  I have used such a system,
and did not think it so wonderful, but for the sake of argument,
let us assume that CR really is objectively better than CS---so
much so that 5BSD and System V Release N+1 will have CR style file
systems.  Fine.

But as I understand it, POSIX is intended to be an interface
specification for something that resembles `Unix' (whatever `Unix'
may be).  If that is indeed the case, the only sensible choice is
CS, for, as I noted above, this is what all major Unix variants
*do*.  *They all agree:* file names are case sensitive.  Should
we make standard something that no one uses?  I say no!  When
5BSD and Release N+1 come out, then we can create a new standard
to describe these wonderful new systems, but until then, let
us write something that describes what we have now.

I believe that the first standard for *anything* that already exists
should describe the existing implementations, at least wherever
they agree.  Afterward, feel free to invent new improved standards,
so as to foist progress upon vendors.  Indeed, it might not be a
bad idea to publish two standards virtually simultaneously: That
Which Is, and That Which Should Be.  But list first That Which Is.

[ There really are (or at least were) two discussions going on here:
one about what should be in POSIX, the other about what UNIX should do.
I haven't seen any recent arguments that POSIX should do anything but
reflect what UNIX currently does, i.e., case sensitive file names
(really file names as uninterpreted byte streams).  -mod ]

--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept ([phone])
UUCP:    seismo!umcp-cs!chris
CSNet:    chris@umcp-cs        ARPA:    [e-mail]

Volume-Number: Volume 8, Number 34

From news  Tue Nov  4 13:17:49 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
Keywords: horse dead UNIX dmr small simple
Summary: UNIX (dmr) philosophy -- and beating a dead horse
Date: 4 Nov 86 19:17:34 GMT
Draft-9: 2.3.folding

From: [e-mail] (Larry Campbell)
Date: Tue, 4 Nov 86 10:19:11 EST
Organization: The Boston Software Works, Inc.

>From: @SUMEX-AIM.ARPA:MRC@PANDA (Mark Crispin)

>     What we are asking for is that if you try to access the ReadMe
>file by specifying "readme" or "Readme" or "README" or even "rEADmE"
>you should get the ReadMe file instead of a file not found error.
>Furthermore, if you open "readme", "Readme", etc. for write, it should
>supercede [sic] the ReadMe file and the resulting file should have the
>original case of ReadMe.
>
>     In other words, finding a file for read will match any case.
>Finding a file for write will match any case, supercede [sic] any such older
>file, and will preserve the case of that older file.  The only way to
>change the case would be with rename; the source name would be case
>independent but the destination case would be preserved.  Of course,
>you could also change the case by deleting ReadMe and then opening
>README for write...

>     There are filesystems that behave in this manner, and they are
>quite pleasant to use.  Please, if you support case-dependence, don't
>give the "mixed case filesystems" class of arguments.  The only two
>arguments you really have are (1) it is a "feature" (however dubious)
>that you can create Makefile and makefile as separate files in the
>same directory, and (2) Unix does it this way.

Sorry to keep beating this dead horse, but some people just haven't
yet caught on to one of the principle design fundamentals of UNIX.

    "Keep it small and simple."

As has already been pointed out, the system (I'm deliberately avoiding
the term "kernel") treats filenames as uninterpreted strings of bytes.
Adding case folding to the system adds complexity to the system that
provides only a tiny benefit (is it really that hard to type the correct
filename?).

I think everyone agrees that creating "Makefile" and "makefile" in the
same directory is braindamaged.  What I disagree with is the notion
that the system should be in the business of preventing this.  Should
the C compiler enforce a certain Hamming distance between identifiers?

Note also that case folding is only "simple" in some languages.  As has
already been pointed out, there are languages (like German) where case
folding is decidedly complex.  And in an international environment, the
case folding algorithm may need to be different for each user.

I wish I could remember who said this, but someone once pointed out
that "One of the reasons Dennis Ritchie is a genius is that whenever
someone says `Wouldn't it be nice if UNIX had feature X?', instead
of saying `Wow, yeah, I'll go hack that in', he says, `Yep, sure would.'"
--
Larry Campbell       MCI: LCAMPBELL          The Boston Software Works, Inc.
UUCP: {alliant,wjh12}!maynard!campbell      120 Fulton Street, Boston MA 02109
ARPA: [e-mail]     [phone]

Volume-Number: Volume 8, Number 35

From news  Tue Nov  4 21:13:05 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: case sensitive filenames
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 5 Nov 86 03:12:53 GMT
Draft-9: 2.3.folding

From: pyramid!utzoo!henry (Henry Spencer)
Date: Tue, 4 Nov 86 19:48:36 CST

> There are also programs (the shell comes to mind) that use the eighth
> bit for their own purposes.  I believe the shell uses it as a quote
> indicator...

I believe that in recent times, AT&T has made strenuous efforts to stamp
out such extraneous uses of the 8th bit, so that full 8-bit character sets
could be used.  I know other vendors have as well.  So this objection will
not be valid much longer, even if it remains valid today.

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

Volume-Number: Volume 8, Number 36

From news  Wed Nov  5 08:55:11 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (now vhangup, auto-nice)
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 5 Nov 86 14:54:41 GMT
Draft-9: job.control

From: seismo!munnari!yabbie.rmit.oz![e-mail] (Ian Donaldson)
Date: Tue, 4 Nov 86 09:05:35ligt

> From: pyramid!nsc!hplabs!hpda!hpisoa1!davel (Dave Lennert)
> Date: Wed, 29 Oct 86 10:07:47 -0800

I spoke about HUP's sent when an _exit is done, not realising at the time
that it is only done by a sesion-group leader, and only to
the same process-group, obviously (it is now) excluding those
processes running in background.

> This key feature is preserved in the POSIX specification.  Perhaps I
> don't understand your statement.

I withdraw the statement.

In the same article, I wrote:

> > 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).
>
> vhangup() is indeed desirable.  It is not required in POSIX because it is
> not supported on System V and, indeed, breaks System V compatiblity.

I forgot to add the other advantage of my vhangup(), in that
any read's by processes from the terminal return EOF rather than
a read-error, and any writes go to the bit-bucket, rather than
producing a write-error.  This is very desirable in stuations where
you have started something in foreground (eg: make, without redirecting I/O) and
you want it to -complete- in background, rather than crash because
it cannot write diagnostics or output...
Of course, you cannot -see- the output, but that is another topic
(along the lines of login-suspension - see ravings in net.unix-wizards
about 6 months ago).

Some programs of course would need to be trained to not repeatedly
read beyond EOF assuming somebody is hitting ^D, otherwise they
will do-so forever.  Berkeley 4.2bsd Csh and Mail already have been
trained, and exit if a certain large number of consecutive EOF's are read.
There are probably others.
We have not felt need to modify any more programs, though there is the stray
program that just sits there all day, once a fortnight perhaps.
Readnews seems to be an often offendor (2.10.3).

I also wrote:

> > Infinite-loop processes don't cause problems with system-response because
> > they are automatically niced (something that is long-needed in UNIX
> > systems).
>
> Note that this is NOT desirable on, e.g., realtime systems where that
> long running process may be critical.  I'm also getting tired of having
> my rwhod reniced automatically.
>
>     Dave Lennert                ucbvax!hpda!davel               [UUCP]

Granted, it probably -isn't- desirable at some sites, or perhaps even
some particular users at certain sites, but it is necessary for
any site that has lots of cpu-intensive tasks mixed in with lots
of heavily interactive (eg: vi) sessions.

The auto-nicing that I have seen in 4.2 (not sure who added it) whereby
a process gets niced by 1 every 40 cpu seconds until the nice reaches +15
is NOT the sort of thing I am talking about.  The obvious problem with
this algorithm is that it makes no distinctions on what it nices -
it nices compiles (ok, good), but it also nices vi (bad), and eventually
nices the shell (worse, as everything you start inherits the nice
from the shell).  It also makes no distinction on -who- it nices;
except that root is never niced (neither are other users, provided
they are running at elevated priority).  This means that all non-root owned
daemons get niced also.

I experimentally implemented a smarter, but still very simple auto-nicing
algorithm that works well here nearly all of the time:  it is an
extension of the one above, except that interactive processes are
identified very simply by the fact that they do tty input (sounds logical).

A process is only niced if it consumes N cpu seconds since last doing
some tty input (we have N set small, to 5 cpu seconds).
This means that an interactive shell is rarely ever
niced, and vi always has a good response time regardless of what
else is going on in the system (unless you're doing complicated
length string searches or the like).  Another "quick hack" allowed
all uid's less-than a certain number (say 2) to be immue to
auto-nicing - this got around the daemon problem, altough very
unelegantly.

The kernel mods were trivial, amounting to less than a screenful
of code all-up.  In a nutshell it was one mod to clock.c
(kern_clock.c for 4bsd), to increment the nice if the conditions
warrant it; and another mod to ttyread() to reset the nice
and the accumulated cpu time since the last ttyread().

I have watched people breath discontent over the net with vi's response time,
and all the hack's that they've tried (including a suid root pre-elevate-nice
command).  Vi is only mentioned because it is common to almost all
systems.  The problem is much deeper than just vi.

Any system that treats non-interactive jobs the same as interactive jobs
is sure to have a rotten response-time.  Interactive jobs are not
jobs that are just "associated" with a terminal either.  People
expecting to do half-hour compiles from the terminal soon learn
that there is no advantage in doing-so, and it is better to come back
later and free up the terminal for somebody else to use (productively).

> Note that this is NOT desirable on, e.g., realtime systems where that
> long running process may be critical.

Perhaps, but then my version of auto-nice may solve most of such
problems anyway.  If the program on the real-time system communicates
with other than tty's in an "interactive" fashion, then this could be
incorporated into the algorithm quite easily.  Lots of things could be
incorporated into the algorithm - such as a per-user nice-rate and
nice-limit.

People will never learn - just telling them to "nice" their jobs
rarely works.  They either forget to, or just don't do it on principle.

SVR2 has no way of renicing a job other than restarting it
(counter-productive), and telling somebody to change their nice on the
humungous compile they just started after they've left and gone home is
also often very difficult (read impossible), leaving a very slow
system.

Vi and similar programs on our systems nearly always have a
good response time - the times that they don't would most probably
be attributed to excess paging and swapping activity and filesystem I/O.

> I'm also getting tired of having
> my rwhod reniced automatically.

Maybe it wouldn't be with the algoritm I mentioned (I've never used
rwhod so I can't answer that).

At least auto-nicing of some variety I have mentioned should
be provided as a standard -option-.  Those who don't like it
can turn it off, but I'll bet your boots that they will be
in a minority once they've tried it.  Not having the option
at all is not very nice (excuse the pun :-).

Ian Donaldson

Volume-Number: Volume 8, Number 37

From news  Wed Nov  5 09:03:56 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: 5 Nov 86 15:03:27 GMT
Draft-9: 2.3.folding

From: seismo!hadron![e-mail] (Joseph S. D. Yao)
Cc: [e-mail]
Date: Tue, 4 Nov 86 21:16:04 est

>From: @SUMEX-AIM.ARPA:MRC@PANDA  (Mark Crispin)
>Date: Mon 20 Oct 86 05:42:50-PDT
>     On the DEC-20 and Unix file servers, it's single case and hyphens.
>I end up using something like "tokyo-paper.first-draft".

This sounds like a local convention.  Unix filenames may contain
any ASCII character, including upper and lower cases, except for
NUL and '/'.

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

We now see the source of the discrepancy.  (2) obviously came first:
people who were used to the older (I did NOT say antique ;-) ) file
system on the 20's, and wanted not to worry about filename conversion,
tried to make the restrictions on Unix file names a combination of
the DEC-20's and what they PERCEIVED as the Unix conventions.  This
indubitably has caused further consternation among people familiar
with one or the other but not both systems.

The Leaf server apparently gives this version of Unix a modified file
system with an attempt at monocase restriction.  I have no idea how
prevalent it is, but my off-hand observation is "not very."  I don't
think arguments based on what it does can be very compelling.
--

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

Volume-Number: Volume 8, Number 38

From news  Wed Nov  5 09:06:09 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: The POSIX file system
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Summary: No matter where the layer, the layers idea is good.
Date: 5 Nov 86 15:05:40 GMT
Draft-9: 2.3.folding

From: seismo!hadron![e-mail] (Joseph S. D. Yao)
Date: Tue, 4 Nov 86 23:03:27 est
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]>:
>From: [e-mail] (Rick Genter)
>Date: 30 Oct 86 09:57:13 EST (Thu)
>
>... various flavors of Unix (such as MERT, Unix' real-time cousin),
>implemented the file system completely outside the kernel, I suppose as a
>library of routines.  ...
>     If any sort of fundamental change is to be made to the file system for
>POSIX, I'd prefer moving towards a non-kernel file system.  In addition to
>simplifying the design of the operating system, it also allows users to
>implement layers on top of the file system, such as case insensitivity,
>wildcard expansion, network file systems, access methods, etc.  Gee, is this
>starting to sound like streams?

The details of implementation, such as in or out of the kernel,
and streams, are really irrelevant.  Having the file system as
a separate, layerable part of the system interface as a whole
is a wonderful idea.  This conforms with ideas of modularity,
motherhood, apple pie, and so forth.  Both 4bsd and s5 have, in
succeeding implementations, tried to isolate FS code at least
by file in the os:sys directories.

Recent versions of the Unix(R) operating systems even implement
file system switches, which are the next great step, and would
probably do everything that Rick or anyone else would like, even
to mounting MS-DOS, VMS, TOPS-20, or whatever file systems.  (Yes,
even 4.2+ FS's on traditional Unix FS's!)  But I haven't seen much
about them since they were first ballyhooed; and AT&T even seems
to be withdrawing theirs.  (They won't document it, saying that
they don't want anyone to use it because it might go away.)  Perhaps
this just means that they're thinking of adopting the Sun version
as a "standard"?  Does anyone know anything about this?
--

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

Volume-Number: Volume 8, Number 39

From news  Wed Nov  5 09:20:53 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
Summary: why?
Date: 5 Nov 86 15:20:23 GMT
Draft-9: 1003.2.getopt

From: seismo!hadron![e-mail] (Joseph S. D. Yao)
Date: Tue, 4 Nov 86 23:13:22 est
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]>:
>From: seismo!unido!exunido!hmm (Hans-Martin Mosner)
>Date: Sat, 1 Nov 86 03:10:54 +0100
>                     ...  So if I happen to have a file
>"-rf" in my home directory and do a "rm *f", I'm out of luck :-)
>I have no solution for this, though...

At least two others have mentioned that something like ./*f does
wonders (if you are aware that it's needed).  My question is, does
anyone have a need for files that start with '-'?  Or is an ounce
of prevention (not using such files) still worth a pound of cure?
(Ignore troff font files: I try to.)

Side note:  the Instructional WorkBench (IWB), in its Unix(R)
Fundamentals course, makes specific note that one should avoid
making files starting with '+' or '-'.  It makes this the specific
subject of one of its programmed-learning questions.
--

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

Volume-Number: Volume 8, Number 40

From news  Wed Nov  5 09:24:50 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]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 5 Nov 86 15:24:17 GMT
Draft-9: job.control

From: seismo!hadron![e-mail] (Joseph S. D. Yao)
Date: Tue, 4 Nov 86 22:47:30 est
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]> you write:
>From: seismo!mcvax!jack
>Organization: AMOEBA project, CWI, Amsterdam
>Date: Tue, 28 Oct 86 23:39:03 +0100
>
>*CURRENT JOB CONTROL IMPLEMENTATIONS ARE HORRIBLE. HORRIBLE!
>HORRIBLE!!!!!!!!*
>Both solutions are filled with horrible tricks like closing
>tty's and re-opening them and then doing funny ioctl()s and the closing
>them again and then reopening then and then...
>It is of course a praiseworthy feat that the folks at HP managed to
>sqeeze those two horrible, inconsistent, unintellegible mechanisms
>into one poor kernel, but I'm afraid the result is horrible**2.
>>From now on, you can find me in the "job control is horrible" camp.

Jack, one gets the vague feeling you dislike these implementations,
without the least notion why.  Could you please meditate, or take a
pill, or whatever soothes you, and then tell us exactly why you feel
this way?  (You may wish to take frequent mellow breaks.)  Perhaps
you could also tell us what you feel defines a non-horrible job
control implementation.  Thank you!
--

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

Volume-Number: Volume 8, Number 41

From news  Wed Nov  5 09:26:51 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: 5 Nov 86 15:26:26 GMT
Draft-9: 1003.2.getopt

From: seismo!mcvax!guido (Guido van Rossum)
Date: Wed, 05 Nov 86 11:24:11 +0100

What nobody seems to have noticed about the proposed "solution" to file
names starting with "-" by prefixing another "-", is that it would break
shell file name expansion.  If you have a file "-foo" in your directory,
the call
    $ blurfl *
will see an option "-foo" rather than a file "--foo".  You can't build
a remedy into the shell's file name generation mechanism unless you plan
to fix all software that ever processes an argv list at the same time
(or build knowledge about programs' command conventions into the shell).

By the way, prefixing with "./" doesn't work at all times either: the
argument need not be a file.  Ever tried to grep for "-1"?  (Grep has a
solution built in: grep -e).

    Guido van Rossum, CWI, Amsterdam <[e-mail]>

Volume-Number: Volume 8, Number 42

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

From: seismo!allegra!phri![e-mail] (Roy Smith)
Date: Wed, 5 Nov 86 09:36:15 EST

> From: seismo!enea!chalmers.UUCP!jacob (Jacob Hallen)
> Given the names Makefile, Readme and Instructions these files will
> appear first in the listing where they are easy to find.

    Doesn't that assume an ASCII collating sequence?

Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

Volume-Number: Volume 8, Number 43

From news  Wed Nov  5 16:13:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: public-domain implementation of V8 "newer"
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 5 Nov 86 22:12:53 GMT
Draft-9: 1003.2.newer

From: harvard!ho3cad!ekb (Eric Bustad)
Date: Wed, 5 Nov 86 15:40:42 CST

This version of "newer" will say that one file is newer that the
other when they are both exactly the same age.  Is this a bug or
does the V8 version of "newer" act this way also?

= Eric Bustad
  AT&T Bell Laboratories
  Holmdel NJ 07733-1988
  [phone]
  [e-mail] or ihnp4!ho3cad!ekb

Volume-Number: Volume 8, Number 44

From news  Thu Nov  6 19:37:19 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  public-domain implementation of V8 "newer"
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Nov 86 01:37:05 GMT
Draft-9: 1003.2.newer

From: [e-mail] (VLD/VMB) (Douglas A. Gwyn)
Date:     Thu, 6 Nov 86 18:48:26 EST

The 8th Ed. UNIX manual says that a zero return code is returned if
the first file's mod time is AT LEAST AS RECENT as the second's (as
well as under other circumstances).  I take this to mean that in case
of an exact tie, the first file is considered "newer" than the second.
I don't know why it's specified this way.

Volume-Number: Volume 8, Number 45

From news  Thu Nov  6 21:32:46 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: public-domain implementation of V8 "newer"
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Nov 86 03:32:30 GMT
Draft-9: 1003.2.newer

From: pyramid!utzoo!henry (Henry Spencer)
Date: Thu, 6 Nov 86 20:53:27 CST

> This version of "newer" will say that one file is newer that the
> other when they are both exactly the same age.  Is this a bug or
> does the V8 version of "newer" act this way also?

The V8 newer does in fact return success (exit status 0) when the files
are exactly the same age.  The name is not entirely right; it should be
something like "up_to_date_with", in an ideal world.  The behavior would
not appear to be a bug, since it is consistent with the wording of the
manual page.

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

Volume-Number: Volume 8, Number 46

From news  Fri Nov  7 07:55:30 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: 7 Nov 86 13:55:01 GMT
Draft-9: 2.3.folding

From: mcvax!axis![e-mail] (Philip Peake)
Date: Fri, 7 Nov 86 09:41:00 -0100
Organization: Axis Digital, 135 rue d'Aguesseau, Boulogne, 92100, FRANCE

In article <[e-mail]>:
>From: [e-mail] (Chris Torek)
>Date: Tue, 4 Nov 86 07:33:44 EST
>
>We seem to have three proposals:
>
>CS: Case sensitive file systems.  This is what all major Unix variants
>    (V6, V7, SysIII, SysV, 2BSD, and 4BSD) now support.
>
>CC: Case coercive file systems (file names forced to all upper or all
>    lower case).
>
>CR: Case retaining but otherwise insensitive file systems (new names
>    are created according to the given case; matches are not case
>    sensitive).
>
>I sincerely hope that no one is seriously suggesting POSIX adopt
>CC: no one seems to like such systems much.

This one line invalidates completely the rest of this article.
WHY do people trying to defend one of their pet ideas always claim
than 'no one' wants the opposite?

There is at least ONE person whod DOES want such filesystems - me!
And I DO suggest that POSIX adopt such a system.

Philip

[ Nor are arguments consisting solely of "I want it" very useful.  -mod ]

Volume-Number: Volume 8, Number 47

From news  Fri Nov  7 07:57:39 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: 7 Nov 86 13:57:13 GMT
Draft-9: 1003.2.getopt

From: [e-mail] (Matthew P Wiener)
Date: Fri, 7 Nov 86 03:02:53 PST
Organization: University of California, Berkeley

In article <[e-mail]> seismo!mcvax!guido (Guido van Rossum) writes:
>What nobody seems to have noticed about the proposed "solution" to file
>names starting with "-" by prefixing another "-", is that it would break
>shell file name expansion.

Of course, but it is trivial (if ugly) to get around, using backquotes.

The reason I am interested is because it came up years ago.  I overloaded
the command line with arguments so that my program could run on our high
speed batch only machine.  And there was one die hard from our batch machine
who liked punctuation marks as his first character.  (The other machine had
a completely different argument convention, so there were different taboo
names.)  And yes, I had strings and post-filename flags in the command line
to boot.

If getopt is to be the standard, a -+ flag to turn flags back on should be
added.  Except for -- -+, meaning file -+.  (But then, somebody is going to
break on that by having a null name show up in between a -- and -+ from an
uncareful $variable expansion.  Weee!)

ucbvax!brahms!weemba    Matthew P Wiener/UCB Math Dept/Berkeley CA 94720

Volume-Number: Volume 8, Number 48

From news  Sat Nov  8 17:17:08 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: 8 Nov 86 23:16:52 GMT
Draft-9: 2.3.folding

From: seismo!enea!chalmers.UUCP!jacob (Jacob Hallen)
Date: Fri, 7 Nov 86 23:35:50 -0100
Organization: Dept. of CS, Chalmers, Sweden

>We seem to have three proposals:
>
>CS: Case sensitive file systems.  This is what all major Unix variants
>    (V6, V7, SysIII, SysV, 2BSD, and 4BSD) now support.
>
>CC: Case coercive file systems (file names forced to all upper or all
>    lower case).
>
>CR: Case retaining but otherwise insensitive file systems (new names
>    are created according to the given case; matches are not case
>    sensitive).
>

There is a serious flaw in the CR case! You lose orthogonality in
the interpretation of commands since creations, moves, copies and
some other file operations will interpret arguments literally while
other commands will have their arguments interpreted in the flexible way.
A move by the way is a good example since one argument will be treated
in one way and the other in the other way.

Jacob Hallen

Volume-Number: Volume 8, Number 49

From news  Sat Nov  8 19:58:46 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: File extents in multiples
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Nov 86 01:58:30 GMT
Draft-9: performance.files

From: ihnp4!uiucdcs!mycroft.GSD!ccvaxa!aglew (Andy Glew)
Date: Fri, 7 Nov 86 09:08:43 CST

Extending files in multiples of a basic unit
--------------------------------------------

A comment on some of the proposals for high-performance file systems
under UNIX that I've seen coming out of the various standardization efforts.
Most have the concept of `extents` or `units` - providing for automatic
extension of file space in pieces of some minimum size. But there
is nothing to say that the system can't allocate extents larger than
the minimum, that are not multiples of the minimum.

What happens if we are storing a large data structure in the file, and we want
to be sure that we can read in the whole data structure in one gulp? Say that
this dataset is 4 tracks long. Obviously, we specify a minimum extent of 4
tracks. But what if the system gives us 5 tracks in an extent? Then we start
the transfer, and have to pause in the middle?

Seems to me that it would be desirable to be able to say that all extents
should be a MULTIPLE of some basic number of blocks. Then you can use
anticipatory fseek'ing to guarantee fast transfer when you want it. Of course,
the possible multiples would be sharply constrained, but with a
getminimumextentsize() primitive portable programs could be written,
assuming extents have to be multiples of that size.

Volume-Number: Volume 8, Number 50

From news  Sat Nov  8 20:02:48 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: 9 Nov 86 02:02:32 GMT
Draft-9: job.control

From: ihnp4!iwtpu!katzung (Brian Katzung)
Date: Sat, 8 Nov 86 14:59:33 CST

     I guess I'm being sort of lazy... I haven't even figured out the
relationship between "P1003" and "POSIX" (I got in late on the discussion),
[ IEEE P1003 is the committee; P1003.1 is the subcommittee that produced
the POSIX Trial Use Standard.  -mod ]
but I wanted to point out one shortcoming of the 4.xBSD implementation of
job control so that it might be avoided in the future.

     The wait3 system call has provisions for informing the parent when a
child is suspended, but not when it resumes.  Thus, if an agent other than
the parent resumes the child, the parent doesn't know about it.  This is
rare, but not unimaginable.  I've had applications that could have been
enhanced if the mechanism were "balanced".

     I haven't checked 4.3, but the 4.2 csh, in particular, won't send a
STOP or TSTP to a process that it believes is already stopped.
-- Brian Katzung  ihnp4!{laidbak,iwtpu}!katzung

Volume-Number: Volume 8, Number 51

From news  Sat Nov  8 21:02:18 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Guest Moderator
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 9 Nov 86 03:02:02 GMT
Draft-9: mod.std.unix

Since I'm going away for a few weeks to do some consulting,
there will be a guest moderator.  He's John B. Chambers,
and has done this several times before.  Please send submissions
to ut-sally!std-unix or [e-mail] (we're both
in those aliases) instead of to my personal addresses.

Volume-Number: Volume 8, Number 52

From news  Mon Nov 17 12:48:15 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: file times and shell commands
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 17 Nov 86 18:48:02 GMT
Draft-9: 1003.2.newer

>From gatech!gitpyr![e-mail] Mon Nov 10 10:46:07 1986
Date: Mon, 10 Nov 86 09:29:38 est
From: Jay Joiner <gatech!gitpyr![e-mail]>
News-Path: gatech!ut-sally!std-unix

About the file times question, how about using ls -t to put the files in
time order, then scanning the list with awk to find out whether the
files in question are in the right order or not.

Jay Joiner


Volume-Number: Volume 8, Number 53

From news  Mon Nov 17 12:49:19 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 P1003 Portable Operating System for Computer Environments Committee
References:
Date: 17 Nov 86 18:49:07 GMT
Draft-9: 2.3.folding

>From im4u![e-mail] Mon Nov 10 16:31:53 1986
Date: Mon, 10 Nov 86 16:40:48 EST
From: Root Boy Jim <im4u![e-mail]>

Re: Volume-Number: Volume 8, Number 25
>      This gives you all the directory advantages of a case-dependent
> filesystem.  The only "feature" you lose is the ability to create a
> separate Readme, ReadMe, readme, and README set of files.  I personally
> believe that anybody who creates files which differ from case deserves
> to be shot or at least have his employment terminated with extreme
> prejudice.  [ I suggest readers interpret that last sentence as a
> hypothetical statement applying to none of them.  -mod ]

There are several uses I can think of:

    1) linking: cd /etc; ln passwd PASSWD
        This makes it less likely that I will lose my passwd
        file even if I do `rm p*'.
    2) old versions: cd /etc; cp passwd PASSWD
        Keeps a backup version. Note that these two uses may
        conflict if I decide to `cp /dev/null PASSWD'!
    3) filename completion: using (1) an the 4.3 csh, I can type
        `vi /etc/P<ESC><RET>'. Ok, ok, emacs then :-)
    4) intermediate files: instead of picking a new name, I can
        just change case. Yes I know I can use other methods.

While I generally think it undesirable to depend on case for human
distinction, it comes in quite handy sometimes. I have seen the same
trick used in C programs as well, #defining foo to union_name.Foo.
Before you flame the usage, my source is the Berkeley VLSI tools.

    (Root Boy) Jim Cottrell        <[e-mail]>
    Was John Hinckley allowed to watch `Taxi Driver' last night?


Volume-Number: Volume 8, Number 54

From news  Mon Nov 17 12:50:21 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (Brett Galloway)
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
References:
Date: 17 Nov 86 18:50:09 GMT
Draft-9: job.control

>From nsc!hplabs!hpda!hpisoa1![e-mail] Wed Nov 12 16:57:34 1986
Cc: gorodish![e-mail]
Date: Wed, 12 Nov 86 10:42:53 -0800

> [e-mail] (Guy Harris) writes:
> > vhangup() is indeed desirable.  It is not required in POSIX because it is
> > not supported on System V and, indeed, breaks System V compatiblity.
>
> Only if you define "System V compatibility" as "behaves exactly the same as
> some particular implementation of System V".

It is true that vhangup() does not break any documented behavior in
System V or the SVID.  However, the System V implementations I am familiar
with (mainly ATT VAX releases) allow access to open login tty file
descriptors after logout (/dev/tty is the exception).

Again, vhangup() is, in my opinion, preferable for security reasons.  I
do not consider the alternate behavior present in at least some System V
ports worth requiring.

> "vhangup" does two things; it
> sends a SIGHUP to the process group of the terminal in question (which is,
> in fact, similar to what S5 does automatically) and it invalidates file
> descriptors that refer to the terminal.
>
> Some System V implementations do not do this, ...

I'm curious; could you list some of the System V implementations which
disallow access to the login tty (via, e.g., stdout, not /dev/tty) after
logout?  I.e., System V's that have vhangup()-like behavior?

-Dave Lennert   HP   ihnp4!hplabs!hpda!davel


Volume-Number: Volume 8, Number 55

From news  Mon Nov 17 12:52:04 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (now vhangup, auto-nice)
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
References:
Date: 17 Nov 86 18:51:48 GMT
Draft-9: job.control

>From nsc!hplabs!hpda!hpisoa1![e-mail] Fri Nov 14 22:04:25 1986
Date: Fri, 14 Nov 86 14:40:04 -0800

> From: ihnp4!iwtpu!katzung (Brian Katzung)
> Date: Sat, 8 Nov 86 14:59:33 CST
>
>      The wait3 system call has provisions for informing the parent when a
> child is suspended, but not when it resumes.  Thus, if an agent other than
> the parent resumes the child, the parent doesn't know about it.  This is
> rare, but not unimaginable.  I've had applications that could have been
> enhanced if the mechanism were "balanced".

You'd also want to sent SIGCLD under these circumstances, to be complete.

We actually breadboarded exactly this internally at HP.  We decided not
to include it in our product or in our POSIX proposal.  This is because
we wanted to provide an interface that is capable of supporting a 4.2
compatible interface on top of it.  This would require a way to turn off
these enhancements.  E.g., the proposal already contains the following:

    - send SIGCLD on child death        [Sys V compatible]
    - send SIGCLD on child death or stop    [4.2 compatible]

We didn't want to add:

    - send SIGCLD on child death or stop or continue

Similarly for wait3() [now known as wait2()].

I'm not saying this additional functionality isn't useful.  I just feel
that it is not so useful that I wanted to further complicate the
interface for it.

Also note that we wanted to provide an interface that could be easily
implemented on top of existing 4.2.

Anyway, that was our reasoning.

-Dave Lennert   HP   ihnp4!hplabs!hpda!davel


Volume-Number: Volume 8, Number 56

From news  Fri Nov 21 15:09:20 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 P1003 Portable Operating System for Computer Environments Committee
Date: 21 Nov 86 21:08:45 GMT
Draft-9: 2.3.folding

>From uw-beaver!uw-vlsi!mprvaxa!ubc-vision!utai!utcsri!mcgill-vision![e-mail] Wed Nov 19 04:57:50 1986
Date: Sun, 16 Nov 86 02:46:16 EST
From: der Mouse  <uw-beaver!ubc-vision!mcgill-vision![e-mail]>

> Please, if you support case-dependence, don't give the "mixed case
> filesystems" class of arguments.  The only two arguments you really
> have are (1) it is a "feature" (however dubious) that you can create
> Makefile and makefile as separate files in the same directory, and
> (2) Unix does it this way.

I think everyone arguing over case sensitivity is missing something.
Why treat letters specially?  For example, UNIX treats a and A
differently just as it treats = and % differently.  I see no reason to
restrict filenames to [a-zA-Z0-9] and a few special characters like .
and -; and given that uniformity case folding makes as much (or as
little) sense as folding 0123456789 onto !"#$%&'()* (to pick a
particularly silly example).

I would say that (1) is not particularly useful, but it can be nice to
be able to create files named D.mcgill-X04T2 and D.mcgill-X04t2 in the
same directory.  This is less of an issue, though; it's just as easy to
make a program use base-36 as base-62 or base-126.

                    der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision![e-mail]


Volume-Number: Volume 8, Number 57

From news  Fri Nov 21 15:12:21 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 P1003 Portable Operating System for Computer Environments Committee
References:
Date: 21 Nov 86 21:11:54 GMT
Draft-9: 2.3.folding

>From bu-cs![e-mail] Wed Nov 19 07:19:28 1986
Date: Tue, 18 Nov 86 21:35:03 EST
From: bu-cs!bu-cs.BU.EDU![e-mail] (Barry Shein)


The problem with a file system where you cannot have ReadMe and
README is that you are throwing away possibilities. This also
means that I cannot have tmp01234A, tmp01234B, ... , tmp01234a, ...

I fear that although many people have applications that are small and
have small requirements they should not place restrictions on those
with large requirements, use your imagination, consider MasterCard's
data base for a moment or some of the multi-library catalog systems
people are building, they may need (and have machines that have no
trouble with) many thousands of files who's names may serve as primary
keys (why not, it's one way to guarantee write-through on update...)

Next they'll be telling us we should only allow 16-bit ints because
any number larger than 16-bits is hard to type in and error prone
anyhow.

I still suggest the use of 'stty lcase' if that's what you want
(alias run 'stty -lcase; \!* ; stty lcase' :-)

    -Barry Shein, Boston University



Volume-Number: Volume 8, Number 58

From news  Fri Nov 21 15:23:37 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: A convention for -file
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
References:
Date: 21 Nov 86 21:23:22 GMT
Draft-9: 1003.2.getopt

>From munnari!runx.oz![e-mail] Thu Nov 20 01:38:54 1986
Date: Wed, 19 Nov 86 22:15:59 AEST
From: munnari!runx.oz![e-mail] (Dave Horsfall)

It is writ:
    Side note:  the Instructional WorkBench (IWB), in its Unix(R)
    Fundamentals course, makes specific note that one should avoid
    making files starting with '+' or '-'.  It makes this the specific
    subject of one of its programmed-learning questions.

EVERY Unix manual I've seen has said something like "It is unwise
to use file names starting with '-'".  And I've used Unix since
good ol' Edition 5 ...  Don't people read manuals anymore?


Dave Horsfall
Sun Computer Australia



Volume-Number: Volume 8, Number 59

From news  Fri Nov 21 15:27:48 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 P1003 Portable Operating System for Computer Environments Committee
Date: 21 Nov 86 21:27:19 GMT
Draft-9: 2.3.folding

Date: Thu, 20 Nov 86 08:39:02 -0200
From: mcvax!crin![e-mail] (Karl Tombre)
Organization: C.R.I.N., Nancy, France

On use of case in filenames :

>There are several uses I can think of:
>
>    1) linking: cd /etc; ln passwd PASSWD
>        This makes it less likely that I will lose my passwd
>        file even if I do `rm p*'.
>    2) old versions: cd /etc; cp passwd PASSWD
>        Keeps a backup version. Note that these two uses may
>        conflict if I decide to `cp /dev/null PASSWD'!
>    3) filename completion: using (1) an the 4.3 csh, I can type
>        `vi /etc/P<ESC><RET>'. Ok, ok, emacs then :-)
>    4) intermediate files: instead of picking a new name, I can
>        just change case. Yes I know I can use other methods.
>

Well and how about directories? I know at least 2 tools using cases in their
directories : rn (News directory) and mail mode in Unipress emacs (Messages
directory). So I generalized this use. All my directories begin with
uppercase, the other files with lowercase. This provides an easy way to
separate directory from file. Of course, that's what I do in my home
directory, I let /usr, /etc and so on remain in lower case :-)



Volume-Number: Volume 8, Number 60

From jbc  Thu Dec  4 09:18:32 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: file times and shell commands
Summary: Another way to do it
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 4 Dec 86 15:18:16 GMT
Draft-9: 1003.2.newer

From: [e-mail] (glc)
Date: 30 Nov 86 16:02:09 GMT
Organization: AT&T Technologies/Bell Labs, Atlanta

> > There doesn't appear to be any decent way to compare the last modified
> > times of files from the shell...
>
> Before everybody starts inventing their own names for this, it should be
> noted that V8 already has a program for this, newer(1).

The newer(1) program is a very good solution to the problem.  For
those who (for whatever reason) do not wish to implement it, there
is an alternate method using the "make" command.

Make(1) has the "-q" option which causes it to return zero or
non-zero after checking the dependencies.  Here is an example:

  if echo "$DEPENDENT:$CONTROL;:" | make -f - -q
    then # The dependent file is up-to-date
    else # The control file is newer that the dependent file
  fi

Cheers,
  Lindsay

Lindsay Cleveland  (akgua!glc) [phone]   Cornet 583-3909
AT&T Technologies/Bell Laboratories ... Atlanta, Ga



Volume-Number: Volume 8, Number 61

From jbc  Thu Dec  4 09:20:23 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: case sensitive filenames
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
References:
Date: 4 Dec 86 15:20:01 GMT
Draft-9: 2.3.folding

Date: Mon, 1 Dec 86 13:49:52 PST
From: [e-mail] (Guy Harris)

> 4.2BSD refuses to namei a file with 8-bit character(s) because that's a good
> sign that the directory entry has been thumped.  The super-user is allowed
> to namei files with 8-bit characters.

4.2BSD refuses to namei a file with 8-bit character(s) because files like
that are a royal pain to deal with, due to both the Bourne and C shell
stripping all arguments to 7 bits before passing them to programs - not
because they are most likely to appear in smashed directory entries.  The
super-user is NOT allowed to namei files with 8-bit characters; the error
returned in 4.2BSD is EPERM, but that doesn't mean it won't be given to the
super-user.  The error was changed to EINVAL in 4.3BSD.

The point still stands, however, that the kernel shouldn't enforce
restrictions like this.  The System V Release 3 Bourne shell has been fixed
to handle 8-bit arguments, so you can use "rm -i *" or something like that
if you want to remove files with 8-bit characters in their names.  Some
Japanese companies have also fixed the C shell to handle files with names
containing 8-bit characters.


Volume-Number: Volume 8, Number 62

From jbc  Thu Dec  4 09:23:01 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: You wanted weirdnix....
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
References:
Date: 4 Dec 86 15:22:48 GMT
Draft-9: Weirdnix

From: scgvaxd!stb![e-mail]
Date: Tue Nov 25 17:39:33 1986


Ok, lets look at read() and write().
1. There is no requirement that anything written will be available for a
read().
2. There is no requirement that read/write return everything that they can.

In general, you can't require this. The terminal lines are a good example;
writting to a terminal will not result in it being readable; the terminal
drivers only return a line at a time no matter how much is requested. Or
at least, thats what the docs say (I've never actually tested it, but it
seems that if it were false, then type ahead would not work as well.)

In general, it is probably safe to require that anything written to a file
should be available to a subsequent read provided that the read is done on
a file descriptor corresponding to the same name, or a link to the same
named file that was written to, all providing that it is a regular file.
Certainly not for device or special files.

Incidently, don't think that 2 is obvious; my first unix programs assumed
that the O/S would return a number of bytes so that the reads would be
re-aligned on a 512 byte boundary, and that I had to call read() multiple
times until I had gotten everything. I was quite suprised to find that
other people had written stuff that did not do this, and even more
suprised to find that it actually worked. No :-)

        Michael Gersten



Volume-Number: Volume 8, Number 63

From jsq  Wed Dec 10 10:19:11 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: IEEE 1003.1 P.55
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 10 Dec 86 16:18:35 GMT
Draft-9: TZ.P.055

[ This is a reposting of P.55, the P1003.1 Timezones proposal,
due to recent interest coinciding with the meeting of P1003
going on this week in Atlantic City.  -mod ]

From: [e-mail] (Moderator, John Quarterman)
Date: 29 Sep 86 19:14:18 GMT

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


Volume-Number: Volume 8, Number 64

From jsq  Sat Dec 13 11:42:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: ctime - HP proposal
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
References:
Date: 13 Dec 86 17:41:53 GMT
Draft-9: TZ

From: utah-cs!hplabs!hpfcla!hpfclj!hpfcdg!rgt (Ron Tolley)
Date: Wed, 10 Dec 86 18:51:58 est

The HP proposal  boils down to five  changes to the RFC.001  Timezone
Interface  by Robert Elz.  I have  listed  these in order of  importance
with  exception  of the  first  (which  is  really  just a  change  to a
comment).  As it turns out they are also in the order  that  they  would
appear in RFC.001.

[ RFC.001 has been superseded by P.55, which I reposted recently.  -mod ]

<(1) Replace (if it makes any difference) the paragraph>

So, I'm going to propose something that could be inserted into
P1003 (with the obvious extra definitions that I'm going to
leave out on the assumption that everyone knows what they are,
like the definition of the struct "tm").

<with the paragraph>

So, I'm going to propose something that could be inserted into
P1003 (with the obvious extra definitions that I'm going to
leave out on the assumption that everyone knows what they are.)

<(2) Replace the paragraph>

Implementations shall provide the following functions:

    struct tm *gmtime(t) time_t *t;
    struct tm *localtime(t) time_t *t;
    int settz(p) char *p;
    char *asctime(tp) struct tm *tp;
    char *ctime(t) time_t *t;

<with the following paragraphs>

The "tm" structure shall be defined as:

    struct tm {
        int tm_sec;    /\(** seconds (0 - 59) \(**/
        int tm_min;    /\(** minutes (0 - 59) \(**/
        int tm_hour;    /\(** hours (0 - 23) \(**/
        int tm_mday;    /\(** day of month (1 - 31) \(**/
        int tm_mon;    /\(** month of year (0 - 11) \(**/
        int tm_year;    /\(** year \- 1900 \(**/
        int tm_wday;    /\(** day of week (Sunday = 0) \(**/
        int tm_yday;    /\(** day of year (0 - 365) \(**/
        int tm_isdst;    /\(** is DST in effect? \(**/
        long tm_tzadj;    /\(** time zone adjustment \(**/
        char *tm_tnptr;    /\(** points to time zone name \(**/
    };

where  tm_isdst is non-zero if a time zone  adjustment  such as Daylight
Savings Time is in effect,  tm_tzadj is the  difference  between GMT and
local  time  expressed  in  seconds,  and  tm_tnptr  points  to a string
containing the time zone abbreviation.

The tm_isdst,  tm_tzadj, and tm_tnptr members of the tm structure may be
viewed as equivalents to the daylight,  timezone, and tzname[]  external
variables  however  their  values  track  those  in the  rest  of the tm
structure.

Implementations shall provide the following functions:

    struct tm *gmtime(t) time_t *t;
    struct tm *localtime(t) time_t *t;
    int settz(p) char *p;
    char *asctime(tp) struct tm *tp;
    char *ctime(t) time_t *t;
    int strftime (p, n, f, tp) char *p, int n, char *f, struct tm *tp;
    int strctime (p, n, f, t) char *p, int n, char *f, time_t *t;
    time_t mktime (tp) struct tm *tp;

<(3) Add after the paragraph describing ctime the following paragraphs>

strftime:  supports  formatted  output of date and time,  according to a
user-supplied  format string.  Locale-specific  values such as month and
weekday names are provided  according to the currently  defined  locale.
(The  method  of  setting  locale  will  be  addressed   elsewhere.  The
setlocale  or  nl_init   routines  are   currently   available  in  some
implementations.)  Strftime  limits the length of the return string p to
be  no  greater  than  n  characters  (including  the  terminating  null
character).  The  actual  number  of  characters   (excluding  the  null
character)  included in p is returned by each  successful  call.  Unlike
asctime, no newline is automatically appended to the formatted string.

strctime:  also supports formatting but takes time_t *t as an argument.

format:  uses field  descriptors  similar to those in the first argument
to printf(3S).  Numeric  output fields are of fixed size (zero padded if
necessary).  All other  characters  are  copied  to the  output  without
change.  Field descriptors are expanded as follows:

    %a is replaced by the abbreviated weekday name

    %A is replaced by the full weekday name

    %b is replaced by the abbreviated month name

    %B is replaced by the full month name

    %c is replaced by the appropriate date and time representation

    %d is replaced by the day of the month as a decimal number (01
       to 31)

    %H is replaced by the hour (24-hour clock) as a decimal number
       (00 to 23)

    %I is replaced by the hour (12-hour clock) as a decimal number
       (01 to 12)

    %j is replaced by the day of the year as a decimal number (001
       to 366)

    %m is replaced by the month as a decimal number (01 to 12)

    %M is replaced by the minute as a decimal number (00 to 59)

    %n is replaced by a new-line character

    %p is replaced by the equivalent of AM or PM

    %r is replaced by the appropriate (12-hour clock) time
       representation

    %S is replaced by seconds as a decimal number (00 to 59)

    %t is replaced by a tab character

    %U is replaced by the week number of the year with Sunday as the
       first day of the week (00 to 52)

    %V is replaced by the week number of the year with Monday as the
       first day of the week (00 to 52)

    %w is replaced by the weekday as a decimal number [0 (Sunday) to 6]

    %x is replaced by the appropriate date representation

    %X is replaced by the appropriate time representation

    %y is replaced by the year without century (00 to 99)

    %Y is replaced by the year with century

    %Z is replaced by the time zone name

    %% is replaced by %

<(4) Add the following paragraph after those mentioned in (3)>

mktime:  computes a long integer time value from a time value  contained
in a "tm" structure.  The values of tm_wday and tm_yday are  overwritten
during this computation.

<(5) Remove all references to settz().  Localtime will use the value of TZ
to determine the what local time means.  If TZ is not set, then localtime
will return a best guess at localtime.>

Ron Tolley

Volume-Number: Volume 8, Number 65

From jsq  Sat Dec 13 11:54:22 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]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 13 Dec 86 17:54:06 GMT
Draft-9: TZ.P.055

From: seismo!gatech!emory![e-mail] (Arnold D. Robbins {EUCC})
Date: Fri, 12 Dec 86 13:36:36 EST
Organization: Math & Computer Science, Emory University, Atlanta

    Shouldn't there be some indication in errno that no conversion
was found [ by settz -mod ]? Otherwise, how is one's code supposed to know
that the string passed to settz() was valid and settz() couldn't find a
conversion? Both return -1!

[ Maybe EINVAL?  -mod ]

>4.5.4.2  Description
>    The localtime() function converts the calendar time pointed to
        ^^^^^^^^^^^
I think that this should be 'ctime', as that is the functionality
desribed by the next two lines:

>by timer to local time in the form of a string.  It is equivalent to
>    asctime(localtime(timer))

Otherwise, the proposal looks good to me!
---
Arnold Robbins
CSNET:    arnold@emory    BITNET:    arnold@emoryu1
ARPA:    [e-mail]
UUCP:    { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold


Volume-Number: Volume 8, Number 66

From jsq  Sat Dec 13 12:01:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: time for time details
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 13 Dec 86 18:00:47 GMT
Draft-9: TZ

From: utah-cs!hplabs!hpfcla!hpfclj!hpfcdg!rgt (Ron Tolley)
Date: Thu, 11 Dec 86 18:16:53 est

GMT and UTC are not the same.

The  following  is a list of leap  seconds  which  have  been  added  to
Universal Coordinated Time (UTC) in order to keep it relatively close to
solar time.  Note that with  Greewich Mean Time, such  corrections  were
made  by  stretching  or  contracting  the  length  of  seconds.  UTC is
generally available through time standards, GMT not readily available.

    1)    1972 June 30 23:59:60
    2)    1972 June 30 23:59:61
    3)    1973 June 30 23:59:60
    4)    1974 June 30 23:59:60
    5)    1975 June 30 23:59:60
    6)    1976 June 30 23:59:60
    7)    1977 June 30 23:59:60
    8)    1978 June 30 23:59:60
    9)    1979 June 30 23:59:60
    10)    1981 June 30 23:59:60
    11)    1982 June 30 23:59:60
    12)    1983 June 30 23:59:60
    13)    1985 June 30 23:59:60

This is data derived from an AP story from May 1985.  No data since then
is known.  There is also no indication  whether the insertions were made
in local time or in UTC.  Local time is  assumed.  (Wouldn't  Australia,
Newfoundland,  and other half-hour-off places have fun with inserting an
extra second in the middle of a pseudo-random hour.)

This  information  has been pieced  together from scattered  sources.  I
reserve the right to be proven wrong.

Ron Tolley

Volume-Number: Volume 8, Number 67

From jsq  Tue Dec 23 10:50:58 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: time for time details
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 16:50:43 GMT
Draft-9: TZ

From: [e-mail] (Guy Harris)
Date: Sat, 13 Dec 86 14:14:04 PST

> GMT and UTC are not the same.

However, it's not clear whether the term "GMT", when used in documents
describing the way UNIX handles time, refers to GMT or to the time that
would be kept by a clock set to local British time at some point when
British Summer Time is not in effect and then left to run free.

Since, as you point out, GMT is not readily available from time sources, and
since most hardware and most implementations don't know how to stretch or
shrink seconds, I suspect most implementations definitely don't provide real
live GMT.  In fact, since most hardware doesn't receive any UTC broadcasts,
most implementations don't provide real live UTC, either.  (Some machines
don't even do that great a job at providing *any* sort of
precise-to-the-second indication of current time, given the tendency of
their clocks to drift, or the fact that their clocks are set from somebody's
wristwatch.)

This is all somewhat irrelevant to machines that don't synchronize with UTC
and don't know about leap seconds.  Machines that do synchronize with UTC
will have to worry about whether particular time zones follow UTC or not.
If they insert the leap seconds at the same instant that UTC does, there's
no real problem; if they don't, the offset between UTC and local time
presumably just slowly drifts from being an even number of half-hours.

Volume-Number: Volume 8, Number 68

From jsq  Tue Dec 23 11:01:14 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Adding leap seconds to UTC
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 17:00:59 GMT
Draft-9: TZ

From: harvard!EDDIE.MIT.EDU!mit-eddie!cullvax!drw (Dale Worley)
Date: Mon, 15 Dec 86 14:27:02 est

The leap second would have to be added at the same time everywhere
(about 00:00 "GMT"), otherwise UTC wouldn't be "coordinated", i.e.,
the same everywhere.  If it sounds weird to stick an extra second in a
random hour in Australia, think of what would happen if UTC was
different between Australia and Britain by one second for several
hours of a random day!

Dale

Volume-Number: Volume 8, Number 69

From jsq  Tue Dec 23 11:05:15 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: strftime et al.
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 17:05:01 GMT
Draft-9: TZ.strftime

From: [e-mail] (Chris Torek)
To: [e-mail], hpfcdg![e-mail]
Date: Mon, 15 Dec 86 16:25:27 EST

The time string formats seem to express a fair number of similar
numeric entities:
...
>    %H is replaced by the hour (24-hour clock) as a decimal number
>       (00 to 23)
>    %I is replaced by the hour (12-hour clock) as a decimal number
>       (01 to 12)
...
>    %U is replaced by the week number of the year with Sunday as the
>       first day of the week (00 to 52)
>    %V is replaced by the week number of the year with Monday as the
>       first day of the week (00 to 52)
>    %w is replaced by the weekday as a decimal number [0 (Sunday) to 6]
...
>    %y is replaced by the year without century (00 to 99)
>    %Y is replaced by the year with century

Now, time conversion may or may not be anywhere near as complex a
task as terminal control, but it seems to me that we may be repeating
the mistake made with termcap, repaired in terminfo.  Rather than
defining a specific set of numeric values, perhaps strftime, like
terminfo, should have a small calculator built in.  Then, e.g.,
`%y' and `%Y' are unnecessary.  `%y' could push the year-with-century,
and `%{100}' the value 100; invoking mod (`%%'? the name may prove
problematical) and `%2d' could then produce the year-without-century.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept ([phone])
UUCP:    seismo!mimsy!chris    ARPA/CSNet:    [e-mail]

Volume-Number: Volume 8, Number 70

From jsq  Tue Dec 23 11:10:25 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: 1003.2 Quarterly Report
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 17:10:10 GMT
Draft-9: 1003.2.Quarterly.Report

From: seismo!amdahl![e-mail] (Hal Jespersen)
Cc: meccts![e-mail]
Date: Sun, 14 Dec 86 15:02:33 PST

John, here is the quarterly report from 1003.2, which you may post to
mod.std.unix, if you feel it is of general interest.  I'm copying the
posix mailing list, FYI.  The actual list of commands I refer to in this
report will be in my next posting.  That should get some comments, I'd
think.


           P1003.2 Working Group Quarterly Report-December 1986

                              Hal Jespersen

                            Amdahl Corporation


       December 14, 1986

       The P1003.2 Shell and Utilities Working Group met in
       Atlantic City, NJ, December 8 and 9, 1986.  The meeting was
       one and a half days, concurrent with 1003.3 and the 1003.1
       Real Time Subcommittee, and prior to the 1003.1 Working
       Group meeting.

       The following were the highlights of the meeting:

          + Three proposals for command groups were received and
            reviewed.  AT&T presented their System V Interface
            Definition (SVID) grouping-a base, plus extensions.
            Doug Gwyn of the U.S. Army presented his idea of a
            single command group, with recommended inclusions.  The
            X/OPEN Group forwarded its list of commands, divided
            into a mandatory group and an optional software
            development group.  The Working Group adopted this
            latter approach for its Draft 2:  an ``Execution
            Environment'' and an optional ``Software Development
            Environment.'' A mandatory ``Application Installation
            Environment'' is also being considered.

          + The Working Group tentatively approved the contents of
            the command environments.  From a list of 141 common
            commands, it categorized them as follows:

              __________________________________________________
             |            |  Included |  Excluded |  Undecided |
             |____________|___________|___________|____________|
             | Execution  |     58    |     18    |      34    |
             |____________|___________|___________|____________|
             | Development|     17    |      3    |      11    |
             |____________|___________|___________|____________|

          + Both AT&T and X/OPEN have offered the use of their
            command documentation as a basis for the proposed
            standard.  Non-disclosure agreements are being analyzed
            for IEEE's approval.

          + Draft 2 of the proposed standard will include command
            descriptions for all commands selected in this meeting.
            The initial source will be the SVID.

          + The Working Group encountered its first pressure to
            accommodate international character sets, date formats,
            collating sequences, etc.  A proposal on ``regular
            expressions'' will be forwarded to the /usr/group
            Technical Committee on Internationalization for its
            comments and recommendations.

       The next meeting is scheduled for April 20 and 21, 1987, in
       Toronto.  It will be two full days, beginning at 9:00 am
       each day.  The 1003.1 meeting will follow for the remainder
       of the week.

       Subsequent meetings:

          + June 24 through 26, 1987, in Seattle.  (1003.1 will
            precede.)

          + September 14 through 16, 1987 (dates approximate), in
            the Boston vicinity.


                                     Hal Jespersen
                                     Amdahl Corp.
                                     M/S 316
                                     1250 East Arques Ave
                                     Sunnyvale, CA 94088
                                     ...{ihnp4|hplabs|seismo|decwrl}!amdahl!hlj
                                     [phone]


Volume-Number: Volume 8, Number 71

From jsq  Tue Dec 23 11:19:43 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: 1003.2 Command Groups
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 17:19:30 GMT
Draft-9: 1003.2.Command.Groups

From: seismo!amdahl![e-mail] (Hal Jespersen)
Date: Sun, 14 Dec 86 15:49:17 PST

The following commands were considered by the 1003.2 Working Group
for inclusion in Draft 2.

Strong Support for INCLUSION in "Execution Environment" (mandatory)

    ar          awk        basename      cat        cd
    chgrp          chmod        chown      cmp        comm
    cp          cut        date      dd        diff
    dirname          echo        ed          egrep        expr
    false          find        getopts      grep        join
    kill          ln        logname      ls        mkdir
    mkfifo          mv        od          paste        pr
    pwd          rm        rmdir      sed        sh
    sleep          sort        stty      sum        tar
    tee          test        touch      tr        true
    tty          umask        uname      uniq        wait
    wc

Strong Support for INCLUSION in "Software Development Environment"
(optional)

    admin          cc        delta      get        ld
    lex          make        prs          rmdel        sact
    size          time        unget      val        what
    xargs          yacc

Strong Support for EXCLUSION (from either environment)

    as          banner        cal          calendar    cu
    dis          mknod        news      nl        red
    rsh          sdb        shl          uucp        uulog
    uuname          uupick        uustat      uuto        uux
    vi          wall        write

No Decision Yet

    at          batch        cancel      cflow        chroot
    col          cpio        cpp          crontab    csplit
    cxref          df        dircmp      du        env
    ex          file        id          line        lint
    lorder          lp        lpstat      m4        mail
    mailx          mesg        newgrp      nm        nohup
    pack          passwd        pcat      pg        prof
    ps          spell        split      strip        su
    tabs          tail        tsort      unpack    who

For those who haven't kept up with the 1003.2 charter, a brief word of
explanation.  We have tended to exclude commands that are not useful
when called from application C programs and shell scripts; vi and sdb
are good examples of these.

The total list of commands considered was provided by the X/OPEN Group,
which seemed like a reasonable starting point.

The Working Group solicits your opinions on these groupings and on the
specific commands selected for each.


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


Volume-Number: Volume 8, Number 72

From jsq  Tue Dec 23 11:26:48 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: time for time details
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 17:26:33 GMT
Draft-9: TZ

From: seismo!nbires!vianet!devine (Bob Devine)
Date: Wed, 17 Dec 86 19:39:53 EST

  This is in response to Ron Tolley's article that appeared in mod.std.unix
last week.  My reply corrects the errors.

Bob Devine

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

> GMT and UTC are not the same.

  Yes they are (within a very small delta).  GMT (Greenwich Mean Time)
is maintained by the UK while UTC (Universal Coordinated Time) is maintained
by the International Time Bureau in Paris (BIH).  The WWV* broadcasts in the
US are not exactly UTC but neither is GMT.  However, they are within
nanoseconds of UTC.  WWV (and WWVB and WWVH) are the US's official
distributors of the time according to the US's clocks.

  Some confusion results from the use of "GMT".   In common usage, it
means what time it is in the timezone centered on the Greenwich Observatory
which defines zero degrees longitude.  It also means the official UK
time.  GMT is no longer the global standard for time; UTC is (since 1972).

  UTC is an average of all the contributing countrys' clocks (US, UK,
France, Italy, Japan etc all contribute to UTC).  The change of UTC
to stay close to UT1 (the "spinning earth" time) is through the adding
or subtracting of leap seconds.  BIH makes recommendations for such
leap seconds and it is up to the individual countries to follow them.
I don't know of any case where a leap second recommedation was not
followed by a country for its clocks; it doesn't make sense to disregard them.


> The  following  is a list of leap  seconds  which  have  been  added  to
> Universal Coordinated Time (UTC) in order to keep it relatively close to
> solar time.  Note that with  Greewich Mean Time, such  corrections  were
> made  by  stretching  or  contracting  the  length  of  seconds.  UTC is
> generally available through time standards, GMT not readily available.
> This is data derived from an AP story from May 1985.  No data since then
> is known.  There is also no indication  whether the insertions were made
> in local time or in UTC.  Local time is  assumed.  (Wouldn't  Australia,
> Newfoundland,  and other half-hour-off places have fun with inserting an
> extra second in the middle of a pseudo-random hour.)

  A second is not stretched/contracted for leap second adjustments.  The
selected minute will have 59 or 61 seconds.  There are agreements as to
which minute is selected and the BIH issues its recommendation far in
advance selecting the minute.  Currently, and unless the earth goes wacko,
a second is usually added once a year.

Bob Devine

Volume-Number: Volume 8, Number 73

From jsq  Tue Dec 23 12:21:14 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: ctime - HP proposal - bug
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 23 Dec 86 18:20:48 GMT
Draft-9: TZ

From: [e-mail]
Date: Tue, 16 Dec 86 12:29:00 EST

> From: utah-cs!hplabs!hpfcla!hpfclj!hpfcdg!rgt (Ron Tolley)
> Date: Wed, 10 Dec 86 18:51:58 est
>
> The HP proposal  boils down to five  changes to the RFC.001  Timezone
> Interface  by Robert Elz.  ...
>
>     %U is replaced by the week number of the year with Sunday as the
>        first day of the week (00 to 52)
>
>     %V is replaced by the week number of the year with Monday as the
>        first day of the week (00 to 52)

While I like the overall idea, this part needs work.

1. Is week 01 the first complete week?  Or is week 00 the first full week
   or fragment of one?

2. If the year begins on Saturday and ends on Monday, it will have 54
   weeks.  Obviously they cannot be numbered 00 to 52!

By the way, how about using %P for AM/PM and %p for am/pm?

Volume-Number: Volume 8, Number 74

From jsq  Tue Dec 23 20:10:23 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: End of Volume 8 of mod.std.unix
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 24 Dec 86 02:09:45 GMT
Draft-9: mod.std.unix

This is the end of Volume 8 of mod.std.unix (aka [e-mail]).
Volume 9 will commence with the new year.  Submissions arriving meanwhile
will be saved for later posting.

Volume-Number: Volume 8, Number 75