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

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

From [e-mail] Tue Jun 25 23:16:34 GMT 1985
Path: ut-sally![e-mail] (John Quarterman)
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix created
Message-ID: <[e-mail]>
Date: 25 Jun 85 23:16:34 GMT
Sender: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 34
Approved: [e-mail]
Draft-9: mod.std.unix

This moderated newsgroup, mod.std.unix, is for discussions of UNIX
standards, in particular the one in progress by the IEEE P1003 "UNIX
Standards" committee.  P1003 is the successor to the /usr/group
standards committee, and many of the members are the same.

The newsgroup moderator is me, John Quarterman.  I got into this
because the USENIX board appointed me to be the USENIX delegate
to P1003.  My function is largely to relay information between
the committee and the USENIX board and membership (I also vote
for USENIX in cases where that is appropriate).  The committee
considers this newsgroup to be one good way to do that.  I will
report on the contents of the newsgroup to the committee, for the
benefit of those who do not follow the newsgroup directly.

While various P1003 committee members will probably post things
to mod.std.unix, it is best to assume that such postings are
personal opinions of the poster, not the official position of
the committee, nor even of the poster's company, unless it is
specifically stated otherwise.

To start with, the newsgroup will go out as individual articles.
If volume builds, I will probably change to a digest format,
so that discussions can be grouped together.

Please mail submissions for mod.std.unix to ihnp4!ut-sally!std-unix,
and comments about the newsgroup to ihnp4!ut-sally!std-unix-request.
(The ARPA Internet addresses, e.g., [e-mail], also work.)
Mail to my personal mail address (below) will be treated as not
for posting, though I may reply with a request for permission to post.

--
John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 01

From [e-mail] Fri Jun 27 15:58:07 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: command line arguments
Message-ID: <[e-mail]>
Date: 28 Jun 85 15:58:07 GMT
Organization: U. Texas CS Dept., Austin, Texas
Lines: 29
Approved: [e-mail]
In-Reply-To: <[e-mail]>
Draft-9: 1003.2.getopt

some commands take arguments as

command -abcdefg filename

and some as

command -a -b -c -d -e -f -g filename

It would be great if this was standardised.
Post this if you like: it's gleaned from a book 'Unix for beginners' by
Miller and Boyle at the University of Leeds, UK
--
 'He had a certain naive charm, but no muscle!'
                     Frank N. Furter in the Rocky Horror Picture Show.

+-------------------------+------------------------------------------+
| Douglas Spencer         | {decvax,garfield,okstate,philabs,seismo} |
|  Maths Institute        |      !mcvax!ukc!warwick!daisy!maugg      |
|   University of Warwick |------------------------------------------|
|    Coventry CV4 7AL     | If necessary I can also be contacted     |
|     England             | easily by any competent telepath     :-) |
+-------------------------+------------------------------------------+

[ The P1003 draft standard has little to say about commands, as it's
mostly concerned with system calls and library routines.  Varying option
formats are a nuisance, though.  -mod]
--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 02

From [e-mail] Sun Jun 30 02:52:52 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-ID: <[e-mail]>
Date: 30 Jun 85 02:52:52 GMT
Reply-To: cyb-eng!bc
Organization: U. Texas CS Dept., Austin, Texas
Lines: 42
Approved: [e-mail]
In-Reply-To: your article <[e-mail]>
Draft-9: 1003.2.getopt

> some commands take arguments as
>
> command -abcdefg filename
>
> and some as
>
> command -a -b -c -d -e -f -g filename
>
> It would be great if this was standardised.

Although commands like find will, I suppose always be renegades, doesn't
conformity to getopt() for all future commands not explicitly excused from
conformity by some ANSI committee take care of the problem?  It seems that
this is (or at least SHOULD be) simply a problem of living with history.

By the way, I understand that the central concern of the committee is in
the area of system calls, but aren't y'all going to have a subcommittee
responsible for commands, shells, etc analogous to the C committee's
"library" subcommittee?  I would hope so.

[ Would some more knowledgable P1003 committee member please comment
on this?  -mod]

If this kind of stuff should be sent to ut-sally!std-unix instead of
ut-sally!jsq, let me know.

[ The convention I have adopted is that mail to ut-sally!std-unix
is a submission to the newsgroup, while mail to ut-sally!jsq (or,
better, ut-sally!std-unix-request) is mail about the newsgroup,
though I may, as I did for this message, reply with a request
for permission to post.  -mod]

bc
--
  /  \    Bill Crews
 ( bc )   Cyb Systems, Inc
  \__/    Austin, Texas

[ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc
--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 03

From [e-mail] Mon Jul 01 16:16:37 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-ID: <[e-mail]>
Date: 1 Jul 85 16:16:37 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 154
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Quarterman (moderator) <ut-sally!std-unix>

Topic: getopt (command line arguments)

The previous posting about standardization of command line options
produced several comments about getopt, one of which I have already
posted.  I've picked out new information from the others and included
them here, after an excerpt from the original posting.

If your mail isn't excerpted here, it's not that I'm ignoring you:  it's
merely that either yours duplicated what earlier mail had already said,
or it was mailed to ut-sally!jsq rather than ut-sally!std-unix
and I haven't gotten confirmation, or it never got to me.

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

Date: Thu, 27 Jun 85 18:08:26 bst
From: Douglas Spencer <seismo!mcvax!daisy!maugg>
Subject: Re: mod.std.unix created
To: ut-sally!jsq

> some commands take arguments as
>
> command -abcdefg filename
>
> and some as
>
> command -a -b -c -d -e -f -g filename
>
> It would be great if this was standardised.

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

Date: Sat, 29 Jun 85 08:42:41 edt
From: Marty Shannon <seismo!allegra!eagle!mjs>
Subject: Re: command line arguments
To: ut-sally!jsq

Perhaps this should really be a followup rather than a reply, but there is a
fairly strong move to standardize command argument parsing by using the getopt
routine.  It deals quite well with the problem, as well as providing a great
deal of flexibility.

    Marty Shannon
UUCP:    ihnp4!eagle!mjs
Phone:    [phone]

[ Someone else notes in mail that the AT&T command line argument standard
is included in the System V Interface Definition, page 343 of the Spring
1985 edition, and getopt conforms to this standard. -mod]

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

Date: 29 Jun 85 23:49:35 CDT (Sat)
From: Henry Spencer <ihnp4!utzoo!henry>
Subject: Re: command line arguments
To: ihnp4!ut-sally!std-unix

There is an AT&T standard for command argument syntax, and the getopt(3)
parser which encourages its use.  (Incidentally, the standard says that
both (for example) "ls -al" and "ls -a -l" are legit.)  AT&T has published
its own getopt() sources to encourage use of getopt, and there is also
an explicitly public-domain implementation that was published on the net
some time ago (by me).

[ I find the following articles in net.sources about getopt:

>From: [e-mail] (Henry Spencer)
Subject: public-domain getopt
Message-ID: <[e-mail]>
Date: Thu, 12-Apr-84 16:41:58 CST

>From: [e-mail] (Tony L. Hansen)
Subject: Re: public domain getopt
Message-ID: <[e-mail]>
Date: Tue, 1-May-84 09:54:16 CDT

>From: [e-mail] (Henry Spencer)
Subject: minor bug in public-domain getopt
Message-ID: <[e-mail]>
Date: Tue, 7-Aug-84 15:31:16 CDT

>From: [e-mail] (Keith Bostic)
Subject: public domain getopt(3)
Message-ID: <[e-mail]>
Date: Fri, 24-Aug-84 07:54:08 CDT

The first one is Henry's code, the next two are bug fixes to that,
and the last one is a reimplementation by Keith Bostic.  -mod ]

Here at utzoo, most any time that we do significant work on a Bell program,
we retrofit it with getopt unless its established syntax is seriously
incompatible with this.  And of course all our own code uses it.  Getopt
and its syntax have some defects, but uniformity is such a huge win that
it's overwhelmingly worth it.

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

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

Date:    Sun, 30 Jun 85  01:00 EDT
From: George M. Weaver <ihnp4!psuvax1![e-mail]>
Subject: Re: command line arguments
To: ut-sally!std-unix

     Frank da Cruz's new C-Kermit adopts a set of command line argument
standards that are worth looking at.  He outlines them briefly, and gives
credit to their creators in the Kermit User Manual, part of which I've
included here (without permission -- hope you don't mind, Frank).

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

The C-Kermit command line syntax has been changed from that of earlier releases
of Unix Kermit to conform to the "Proposed Syntax  Standards  for  Unix  System
Commands"  put  forth  by  Kathy  Hemenway  and  Helene  Armitage  of AT&T Bell
Laboratories in Unix/World, Vol.1, No.3, 1984.  The rules that apply are:

   - Command names must be between 2 and 9 characters ("kermit" is 6).
   - Command names must include lower case letters and digits only.
   - An option name is a single character.
   - Options are delimited by '-'.
   - Options with  no  arguments  may  be  grouped  (bundled)  behind  one
     delimiter.
   - Option-arguments cannot be optional.
   - Arguments immediately follow options, separated by whitespace.
   - The order of options does not matter.
   - '-' preceded and followed by whitespace means standard input.

A group of bundled options may end with an option that has an argument.

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


George M. Weaver
Penn State Astronomy Dept.
GMW at PSUVM.BITNET
...!allegra!psuvax1![e-mail]

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

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular the one in progress by the IEEE P1003 "UNIX Standards" Committee.

Please mail submissions to mod.std.unix to ut-sally!std-unix,
and comments about the newsgroup to ut-sally!std-unix-request.
Permission for posting to the newsgroup is assumed for mail
to the former address, but mail to the latter address will
not be posted unless explicit permission is included, or obtained
by later negotiation.  Mail to ut-sally!jsq concerning mod.std.unix
will be treated like mail to ut-sally!std-unix-request.
--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq


Volume-Number: Volume 1, Number 04

From [e-mail] Mon Jul 01 21:52:49 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to P1003 draft and /usr/group standard
Message-ID: <[e-mail]>
Date: 1 Jul 85 21:52:49 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 30
Approved: [e-mail]
Draft-9: D2.Access

From: John Quarterman (moderator) <ut-sally!std-unix>

Several people have asked how to get copies of the /usr/group standard
and the current P1003 draft.

The /usr/group one is

    1984 /usr/group Standard
    prepared by the
    /usr/group Standards Committee
    November 14, 1984
    Copyright 1984 - /usr/group

and is available from

    /usr/group
    4655 Old Ironside Drive, Suite 200
    Santa Clara, California 95050
    U.S.A.

Unfortunately, I don't know the price.


There is a plan to make the current P1003 draft standard available for
UUCP transfer from a well-known UUCP site, and for anonymous ftp from
at least one ARPA Internet host.  The draft is being extensively
revised right now, however, and cannot be made available quite yet.
--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 05

From [e-mail] Mon Jul 01 22:27:43 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 questions and answers
Message-ID: <[e-mail]>
Date: 1 Jul 85 22:27:43 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 63
Approved: [e-mail]
Draft-9: 5.1 6.5.2 8.0

From: John Quarterman (moderator) <ut-sally!std-unix>

Before the Portland USENIX Conference, or, more specifically, before
the P1003 "UNIX Standards" committee meeting which was held on the
three days before that USENIX, I solicited comments and questions about
the P1003 standard on several newsgroups on USENET.  Here are most of
the questions and my interpretation of how they relate to what the
committee is doing.  Be aware that my interpretation may not correspond
to reality, and is certainly not an official statement by the committee.

Is the P1003 draft standard compatible with the X3J11 C draft standard?

    This was one of the main things discussed at the meeting.
    The P1003 committee is very concerned about compatibility
    with X3J11, to the point of replacing large sections of
    the P1003 draft standard with references to the X3J11 standard.
    There are places where it's not that simple, though, such as
    kill(2), because the C standard needs to define a small set
    of functions, while the P1003 standard needs to define others.
    A committee was appointed to communicate with X3J11.

    Someone asked specifically if <limits.h> would be compatible,
    and the intention of the committee is that it will be.

    Someone else asked if signal(2) were defined properly using void.
    At the moment, it's not.  I don't know if it will be later.

Database issues.

    File locking was referred to a /usr/group subcommittee,
    which solicited members at a USENIX BOF.  This was because
    the P1003 members are mostly not database experts, and
    felt that problems with lockf could not be resolved by them
    in a reasonable amount of time.  The committee did remove
    the enforcement mode of lockf from the body of the draft
    to an appendix.

    The 4.2BSD truncate system call is not in the draft standard,
    and thus far no one has proposed that it should be.  Though
    its utility is clear, there seems to be a strong reluctance
    to add new facilities.

Are the 4.2BSD directory routines (opendir, readdir, closedir) included?

    They were recently added, in an appendix.

    Someone asked if the conflicts involving <sys/ndir.h> having
    the same name but different functions on 4.2BSD and other
    systems had been resolved.  The corresponding header file
    is <dirent.h> in the draft standard.

Have windowing, graphics, or network standards been addressed?

    The committee takes pains to avoid precluding network
    implementations of things such as file systems, but
    does not directly address windowing, graphics, or networks.
    There are /usr/group subcommittees on those subjects, however.

    If someone more knowledgeable would post something on the
    /usr/group committees, I would appreciate it.
--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 06

From [e-mail] Tue Jul 02 19:56:12 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-ID: <[e-mail]>
Date: 2 Jul 85 19:56:12 GMT
References: <[e-mail]> <[e-mail]>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 30
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: utastro!nather (Ed Nather)

>      Frank da Cruz's new C-Kermit adopts a set of command line argument
> standards that are worth looking at.
> [...]
> A group of bundled options may end with an option that has an argument.

This creates confusion in using C-Kermit when you want to send an image
file.  For example:

    send -is filename     < ---  works fine
        send -si filename     < ---  bombs the program

I personally find it hard to remember which is which, since they both seem
equally sensible to me.  I would *much* prefer to bundle the flags, then
have those with arguments pick them up in the same order as the flags are
listed.  In the above case, the "-i" flag doesn't take an argument, so I
think it should be processed but should not "shield" the "-s" flag from its
argument.

But what do I know?

Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
[e-mail]

--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 07

From [e-mail] Thu Jul 04 13:37:53 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-ID: <[e-mail]>
Date: 4 Jul 85 13:37:53 GMT
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 76
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Quarterman (moderator) <ut-sally!std-unix>

Topic: more on getopt (command line arguments)

This article will be followed by one more, containing source and man page
for a public domain getopt.  That should about wrap this subject up.  -mod

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

From: Randy D. Smith <ihnp4!decvax!mcnc!rtp47!smithrd>
Date: Mon, 1 Jul 85 07:58:42 edt
Apparently-To: mcnc!ihnp4!ut-sally!std-unix

P1003 definitely intends to address commands and the command
interface (e.g., sh).  That work has been sidetracked in order
to devote our efforts to getting the current core of the draft
(system call stuff) out the door.  I believe everyone on the
committee fully expects that commands/command line will be a
top priority after the draft goes out, is balloted, and the
ballots are resolved.

There has been some consensus already on the command line interface,
based on "An Enhanced Getopt" by T. C. Jones and L. A. Kennedy
of AT&T Bell Labs.  As mentioned in previous messages, this should
help us in the future, although history already stuck us with
a variety of interfaces to existing commands.
--
                Randy D. Smith    [phone]
               Data General, Research Triangle Park, NC
             <the known world>!mcnc!rti-sel!rtp47!smithrd
<General disclaimer:
    :r jsq's original posting about committee member's opinions
    being their own and not that of the entire committee...
>

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

Date: Wed, 3 Jul 85 11:06:19 edt
From: seismo!ulysses!smb (Steven Bellovin)
To: ut-sally!std-unix
Subject: Re: command line arguments

I believe I heard at Usenix that AT&T has put their version of getopt()
into the public domain.  Can anyone confirm this?

        --Steve Bellovin
        ulysses!smb

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

Date: Sat, 29 Jun 85 16:55:37 edt
From: ihnp4!utcs!ian (Ian F. Darwin)
To: ut-sally!jsq

There is an AT&T standard for command line arguments.
It was published about a year ago (washington??).
It is included in the Sys V interface Definition, page 343
of the Spring 85 edition.

There is a routine called `getopt(3)' that parses options
according to this standard. Bell published the `official'
source at UniForum in Dallas; several public-domain versions
(at least one with cleaner coding style!) have appeared on
the net. Send me mail if you don't have a copy, because
*everybody writing C programs should be using getopt()
to parse their command line options*.

Thanks

Ian Darwin, Toronto
ihnp4!darwin!ian

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

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 08

From [e-mail] Thu Jul 04 14:54:39 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-ID: <[e-mail]>
Date: 4 Jul 85 14:54:39 GMT
References: <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 433
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Quarterman (moderator) <ut-sally!std-unix>

Topic: yet more on getopt (command line arguments)

Two more messages, the first a followup to a previous posting, and
the second public domain sources and man pages for getopt(3) and getopt(1).
    -mod

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

From: ihnp4!utzoo!henry
Date: 3 Jul 85 18:34:41 CDT (Wed)
To: ihnp4!ut-sally!std-unix
Subject: Re: command line arguments

> > A group of bundled options may end with an option that has an argument.
>
> This creates confusion in using C-Kermit when you want to send an image
> file.  For example:
>
>     send -is filename     < ---  works fine
>         send -si filename     < ---  bombs the program

The AT&T syntax standard (which getopt does not completely enforce)
actually forbids both of these usages.  Options with arguments are not
allowed to be bundled, and they must be separated from their arguments
by a space.

> I would *much* prefer to bundle the flags, then
> have those with arguments pick them up in the same order as the flags are
> listed.

The few existing commands that use such a convention, notably tar(1), are
(in my experience) the worse for it.  It's seriously error-prone.  I think
the AT&T people did the right thing.

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

Date: Tue, 2 Jul 85 13:07:09 edt
From: ihnp4!utcs!ian (Ian F. Darwin)
To: ihnp4!ut-sally![e-mail]
Subject: here is getopt

Here is the source for getopt(3), the function that should be in
everybody's C program, and getopt(1), a program that uses it to
make shell programs comprehensible and consistent. There are man
pages for both. Please send these on to the mod. group. Thanks.

[ I have hacked the following shell script slightly so that
it doesn't extract directly into system source directories,
rather into the current directory.  It should be assumed that
this code comes with no warranty from me, Ian Darwin, or anyone
else as to whether it accurately represents getopt as distributed
with System V, or any command line standard, or that it works
at all, or that it will cause no damage when extracted or used. -mod]

#! /bin/sh
#! To unbundle, sh this file
echo x - "(/usr/man/man3/getopt.3)" >&2
echo x - mkdir lib >&2
mkdir lib >&2
echo x - lib/getopt.3 >&2
cat >lib/getopt.3 <<"//SYSIN DD SYSOUT=BD"
.TH GETOPT 3 local
.DA 25 March 1982
.SH NAME
getopt \- get option letter from argv
.SH SYNOPSIS
.ft B
int getopt(argc, argv, optstring)
.br
int argc;
.br
char **argv;
.br
char *optstring;
.sp
extern char *optarg;
.br
extern int optind;
.ft
.SH DESCRIPTION
.I Getopt
returns the next option letter in
.I argv
that matches a letter in
.IR optstring .
.I Optstring
is a string of recognized option letters;
if a letter is followed by a colon, the option is expected to have
an argument that may or may not be separated from it by white space.
.I Optarg
is set to point to the start of the option argument on return from
.IR getopt .
.PP
.I Getopt
places in
.I optind
the
.I argv
index of the next argument to be processed.
Because
.I optind
is external, it is normally initialized to zero automatically
before the first call to
.IR getopt .
.PP
When all options have been processed (i.e., up to the first
non-option argument),
.I getopt
returns
.BR EOF .
The special option
.B \-\-
may be used to delimit the end of the options;
.B EOF
will be returned, and
.B \-\-
will be skipped.
.SH SEE ALSO
getopt(1)
.SH DIAGNOSTICS
.I Getopt
prints an error message on
.I stderr
and returns a question mark
.RB ( ? )
when it encounters an option letter not included in
.IR optstring .
.SH EXAMPLE
The following code fragment shows how one might process the arguments
for a command that can take the mutually exclusive options
.B a
and
.BR b ,
and the options
.B f
and
.BR o ,
both of which require arguments:
.PP
.RS
.nf
main(argc, argv)
int argc;
char **argv;
{
    int c;
    extern int optind;
    extern char *optarg;
    \&.
    \&.
    \&.
    while ((c = getopt(argc, argv, "abf:o:")) != EOF)
        switch (c) {
        case 'a':
            if (bflg)
                errflg++;
            else
                aflg++;
            break;
        case 'b':
            if (aflg)
                errflg++;
            else
                bproc();
            break;
        case 'f':
            ifile = optarg;
            break;
        case 'o':
            ofile = optarg;
            break;
        case '?':
        default:
            errflg++;
            break;
        }
    if (errflg) {
        fprintf(stderr, "Usage: ...");
        exit(2);
    }
    for (; optind < argc; optind++) {
        \&.
        \&.
        \&.
    }
    \&.
    \&.
    \&.
}
.RE
.PP
A template similar to this can be found in
.IR /usr/pub/template.c .
.SH HISTORY
Written by Henry Spencer, working from a Bell Labs manual page.
Behavior believed identical to the Bell version.
.SH BUGS
It is not obvious how
`\-'
standing alone should be treated;  this version treats it as
a non-option argument, which is not always right.
.PP
Option arguments are allowed to begin with `\-';
this is reasonable but reduces the amount of error checking possible.
.PP
.I Getopt
is quite flexible but the obvious price must be paid:  there is much
it could do that it doesn't, like
checking mutually exclusive options, checking type of
option arguments, etc.
//SYSIN DD SYSOUT=BD
echo x - "(/usr/man/man1/getopt.1)" >&2
echo x - mkdir bin >&2
mkdir bin >&2
echo x - bin/getopt.1 >&2
cat >bin/getopt.1 <<"//SYSIN DD SYSOUT=BD"
.TH GETOPT 1 local
.DA 12 April 1984
.SH NAME
getopt \- parse command options
.SH SYNOPSIS
.B set \-\- \`getopt
optstring
.B $*\`
.SH DESCRIPTION
.I Getopt
is used to break up options in command lines for easy parsing by
shell procedures, and to check for legal options.
.I Optstring
is a string of recognized option letters (see
.IR getopt (3));
if a letter is followed by a colon, the option
is expected to have an argument which may or may not be
separated from it by white space.
The special option
.B \-\-
is used to delimit the end of the options.
.I Getopt
will place
.B \-\-
in the arguments at the end of the options,
or recognize it if used explicitly.
The shell arguments
(\fB$1 $2\fR ...) are reset so that each option is
preceded by a
.B \-
and in its own shell argument;
each option argument is also in its own shell argument.
.SH EXAMPLE
The following code fragment shows how one might process the arguments
for a command that can take the options
.B a
and
.BR b ,
and the option
.BR o ,
which requires an argument.
.PP
.RS
.nf
set \-\- \`getopt abo: $*\`
if test $? != 0
then
    echo 'Usage: ...'
    exit 2
fi
for i
do
    case "$i"
    in
        \-a|\-b)
            flag=$i; shift;;
        \-o)
            oarg=$2; shift; shift;;
        \-\-)
            shift; break;;
    esac
done
.fi
.RE
.PP
This code will accept any of the following as equivalent:
.PP
.RS
.nf
cmd \-aoarg file file
cmd \-a \-o arg file file
cmd \-oarg -a file file
cmd \-a \-oarg \-\- file file
.RE
.PP
A program template similar to this example can be found in
.IR /usr/pub/template.sh .
.SH SEE ALSO
sh(1), getopt(3)
.SH DIAGNOSTICS
.I Getopt
prints an error message on the standard error output when it
encounters an option letter not included in
.IR optstring .
.SH HISTORY
Written by Henry Spencer, working from a Bell Labs manual page.
Behavior believed identical to the Bell version.
.SH BUGS
Whatever
.IR getopt (3)
has.
.PP
Arguments containing white space or imbedded shell metacharacters
generally will not survive intact;  this looks easy to fix but isn't.
.PP
The error message for an invalid option is identified as coming
from
.I getopt
rather than from the shell procedure containing the invocation
of
.IR getopt ;
this again is hard to fix.
.PP
The precise best way to use the
.I set
command to set the arguments without disrupting the value(s) of
shell options varies from one shell version to another.
//SYSIN DD SYSOUT=BD
echo x - "(/usr/src/lib/libc/gen/getopt.c)" >&2
echo x - lib/getopt.c >&2
cat >lib/getopt.c <<"//SYSIN DD SYSOUT=BD"
/*
 * getopt - get option letter from argv
 */

#include <stdio.h>

char    *optarg;    /* Global argument pointer. */
int    optind = 0;    /* Global argv index. */

static char    *scan = NULL;    /* Private scan pointer. */

extern char    *index();

int
getopt(argc, argv, optstring)
int argc;
char *argv[];
char *optstring;
{
    register char c;
    register char *place;

    optarg = NULL;

    if (scan == NULL || *scan == '\0') {
        if (optind == 0)
            optind++;

        if (optind >= argc || argv[optind][0] != '-' || argv[optind][1] == '\0')
            return(EOF);
        if (strcmp(argv[optind], "--")==0) {
            optind++;
            return(EOF);
        }

        scan = argv[optind]+1;
        optind++;
    }

    c = *scan++;
    place = index(optstring, c);

    if (place == NULL || c == ':') {
        fprintf(stderr, "%s: unknown option -%c\n", argv[0], c);
        return('?');
    }

    place++;
    if (*place == ':') {
        if (*scan != '\0') {
            optarg = scan;
            scan = NULL;
        } else if (optind < argc) {
            optarg = argv[optind];
            optind++;
        } else {
            fprintf(stderr, "%s: -%c argument missing\n", argv[0], c);
            return('?');
        }
    }

    return(c);
}
//SYSIN DD SYSOUT=BD
echo x - "(/usr/src/bin/getopt.c)" >&2
echo x - bin/getopt.c >&2
cat >bin/getopt.c <<"//SYSIN DD SYSOUT=BD"
#include <stdio.h>

main(argc, argv)
int argc;
char *argv[];
{
    extern int optind;
    extern char *optarg;
    int c;
    int status = 0;

    optind = 2;    /* Past the program name and the option letters. */
    while ((c = getopt(argc, argv, argv[1])) != EOF)
        switch (c) {
        case '?':
            status = 1;    /* getopt routine gave message */
            break;
        default:
            if (optarg != NULL)
                printf(" -%c %s", c, optarg);
            else
                printf(" -%c", c);
            break;
        }
    printf(" --");
    for (; optind < argc; optind++)
        printf(" %s", argv[optind]);
    printf("\n");
    exit(status);
}
//SYSIN DD SYSOUT=BD
exit 0

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

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 09

From [e-mail] Thu Jul 04 15:52:35 GMT 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: curses, terminfo, and termcap
Message-ID: <[e-mail]>
Date: 4 Jul 85 15:52:35 GMT
Organization: U. Texas CS Dept., Austin, Texas
Lines: 69
Approved: [e-mail]
Draft-9: curses

From: John Quarterman (moderator) <ut-sally!std-unix>

Topic: curses, terminfo, and termcap

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Please mail submissions to the newsgroup to:    ut-sally!std-unix
Mail to this address will be posted to mod.std.unix unless it is
redundant or otherwise inappropriate, when I will reply by mail
with suggestions on where else it might be appropriate.

Please mail comments about the newsgroup to:    ut-sally!std-unix-request
Mail to this address will not be posted to mod.std.unix unless explicit
permission is included in the mail, though I may reply with a request
for permission to post.  Mail to ut-sally!jsq regarding mod.std.unix
is treated like mail to ut-sally!std-unix-request.

It is possible to reach ut-sally through ihnp4, seismo, gatech, and harvard,
among other UUCP connections, and as ut-sally.ARPA through the ARPA Internet
or CSNET.  -mod

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

Date: Tue, 2 Jul 85 15:49:39 CDT
From: Stan Barber <neuro1![e-mail]>
Subject: curses
Apparently-To: [e-mail]

With the posting of the game "Battleship" in net.sources.games recently
came the realization that curses is not the same on SYSVr2 and BSD.

After reading the instructions on SYSVr2, I think is is more powerful than
the Ken Arnold original. It also seems upward compartable (for the most
part) with Ken Arnold.

I am not sure if curses is considered part of the "standard", but would
like to see some discussion of this as well as the larger issure of
termcap vs. terminfo format for terminal capabilities.
Stan

[
There has been recent discussion of all these things in net.unix.
The System V Release 2 curses has apparently been extensively modified
by Mark Horton, to do input translation, among other things.  He also
appears to be largely responsible for terminfo.

The world seems to be moving from termcap to terminfo (for good reason,
I think).  There is a public domain termcap to terminfo translator.
    From: [e-mail] (Robert Viduya)
    Newsgroups: net.sources
    Subject: termcap to terminfo translator
    Message-ID: <[e-mail]>
    Date: 30 Jan 85 20:42:01 GMT
    Organization: Georgia Tech, Atlanta

A public domain version of curses and terminfo by Pavel Curtis of
Cornell University was posted to mod.sources in December 1984.
It appears to include most of the System V Release 2 innovations.

I seem to recall that terminfo is supposed to be supplied with 4.3BSD,
perhaps as user contributed software, but I don't remember for sure.
    -mod ]

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

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 10

From jsq  Sun Jul  7 10:50:56 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-Id: <[e-mail]>
Date: 7 Jul 85 15:50:48 GMT
References: <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]> <[e-mail]>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 88
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: <[e-mail]> John Quarterman (moderator)

Topic: getopt (command line arguments) continued

This looks like it is going to be a backburner discussion for some time.

It has been noted in mail that the other getopt than the one I posted
may be superior, and that it would be good to post whichever is the best
to mod.sources or net.sources again, as those get archived on many hosts.
Negotiations are in progress.

Note the address for submissions to mod.std.unix is ihnp4!ut-sally!std-unix.
Mark Horton is very efficient, but he's got his own newsgroups to moderate....

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

Date: Wed, 3 Jul 85 16:51:43 edt
From: [e-mail]
Subject: Re: command line arguments
To: [e-mail]
References: <[e-mail]>

> > some commands take arguments as
> >
> > command -abcdefg filename
> >
> > and some as
> >
> > command -a -b -c -d -e -f -g filename
> >
> > It would be great if this was standardised.
>

The thing that burns me about some commands (and these are usually
experimental tools, mind you, real UNIX commands seem to work ok)
is that while most will accept
command -flag           and        command - flag
some will only accept one or the other.
I suppose that its easier to process the latter with a shell script
if you don't use getopt, but it sure is a pain.

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

Date: Wed, 3 Jul 85 12:58:16 cdt
From: neuro1!baylor![e-mail] (Peter da Silva)
Subject: Re: Re: command line arguments
Newsgroups: mod.std.unix
To: neuro1![e-mail]
References: <[e-mail]> <[e-mail]>

:-) Look! No quotes!

I doubt the necessity and even the wisdom of seperating an argument from
the option by whitespace. I also dislike the blackballing of multicharacter
options.

Since no arguments are allowed to be optional there's no point in
distinguishing between '-t/dev/tty4' and '-t /dev/tty4'. Since 't'
requires an argument the parsing is unambiguous.

It makes it harder to write transparent shell scripts. Atomic options make
it much easier to pass stuff onto other programs. Parsing options in shell
scripts is pretty much a lossage anyway, so why make things harder?

As for multicharater options: do you intend to kill "tail -30"? Since
changing the number of lines is the most common case what's the problem?
At any rate you should allow a simple '-nnn' for a high-usage.

[ Since tar is the standard for data interchange (actually, only the
format of the tar data, not the tar program, is currently in the draft
standard), I suspect there will always be anomalies.  The advantage
of getopt is not that it's perfect, just that it's close enough and
widespread enough that it has some chance of being adopted everywhere.
 -mod ]

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

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:    ut-sally!std-unix
Comments about the newsgroup to:    ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.
--

John Quarterman, [e-mail], {ihnp4,seismo,ctvax}!ut-sally!jsq

Volume-Number: Volume 1, Number 11

From jsq  Mon Jul  8 11:33:38 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: curses, terminfo, and termcap
Message-Id: <[e-mail]>
Date: 8 Jul 85 16:33:25 GMT
References: <[e-mail]>
Reply-To: std-unix-request@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 70
Approved: [e-mail]
Draft-9: curses

From: John Quarterman (moderator) <ut-sally!std-unix>

Topic:  curses, terminfo, and termcap

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

Date: Sat, 6 Jul 85 01:06:24 edt
From: cbosgd.ATT!mark@seismo (Mark Horton)
To: [e-mail]
Subject: curses as part of the standard

The System V curses was intended to be mostly upward compatible with
Ken Arnold's version (the one in 4BSD).  It doesn't include a couple
of nonportable features, such as the 2 letter variables in curses.h
and the 4BSD way of getting at your erase character; there are portable
ways of doing this provided.

What I think is important about curses is not the code that implements
it (although this code was hard and it shouldn't have to be done more
than once) but the interface between the program and the package.
Curses is intended as a way to write portable screen oriented applications.
There are a number of functions in curses to enhance portability of the
application, some of which have little to do with screen handling but
seem to be needed by many screen oriented programs.  A curses application
should not care whether it's running on System V, 4.2BSD, or MS DOS.

Simpler implementations of curses that work on a PC make sense.  I know
of two implementations for MS DOS and one for QNX.  I also know of two
for UNIX that don't do optimization of handle braindamaged terminals, but
assume 9600 baud and an ordinary (or specific) terminal.

I personally would like to see curses (or some appripriate subset) become
part of the C standard, along with Standard I/O.  However, it appears that
the committee is not planning to do this.  Lacking this, I would like to
see it become part of a UNIX standard.

    Mark Horton

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

Date: Mon, 8 Jul 85 10:15:56 cdt
From: John Quarterman (moderator) <[e-mail]>
To: std-unix
Subject: public domain curses and terminfo

While I agree with Mark Horton that it shouldn't be necessary to
implement curses more than once, it appears that somebody else has also
done it.  I've gotten a couple of requests for more information on the
posting of it to mod.sources last November.  The first posting
contained this signature:

            Pavel Curtis
        Computer Science Dept.
        405 Upson Hall
        Cornell University
        Ithaca, NY 14853

        Ph- [phone]

        decvax!cornell!pavel        (UUCP)
        Pavel.Cornell@Udel-Relay    (ARPA)

The moderator of mod.sources is genrad!john, who would know better
than I what arrangements have been made for access to mod.sources archives.

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

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 12

From jsq  Mon Jul  8 11:52:09 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: ARPA Internet access to mod.std.unix
Message-Id: <[e-mail]>
Date: 8 Jul 85 16:51:54 GMT
Reply-To: std-unix-request@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 37
Approved: [e-mail]
Draft-9: mod.std.unix

From: John Quarterman (moderator) <ut-sally!std-unix>

Several people have expressed interest in getting mod.std.unix by mail
over the ARPA Internet.  I've set up automatic forwarding of postings
to the newsgroup to a list of Internet addresses from ut-sally.  As long
as the size of the list remains small, I will keep the list on sally.
If it gets large, I will try to find some host better set up for such
forwarding to take it over.

There was a suggestion to funnel mod.std.unix into UNIX-WIZARDS, as
mod.std.c is funnelled into INFO-C.  I think this would be a bad idea,
considering the amount of junk in UNIX-WIZARDS.  Same for INFO-UNIX.

Eventually, I will put a listing in [SRI-NIC]<NETINFO>INTEREST-GROUPS.TXT,
which is the registry for Internet mailing lists.  For the moment, the
appropriate information is as follows:

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.  It is gatewayed to a mailing list on
the ARPA Internet.

Submissions to the newsgroup (permission to post assumed) to:
               UUCP:  ut-sally!std-unix
    ARPA Internet and CSNET:  [e-mail]
Comments about the newsgroup (permission to post not assumed) to:
               UUCP:  ut-sally!std-unix-request
    ARPA Internet and CSNET:  [e-mail]

Mail to my personal addresses about the newsgroup will be treated
like mail to std-unix-request.

Note that ut-sally.ARPA will soon become SALLY.UTEXAS.EDU.
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 13

From jsq  Mon Jul  8 14:40:14 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-Id: <[e-mail]>
Date: 8 Jul 85 19:40:08 GMT
References: <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: std-unix-request@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 94
Approved: [e-mail]
Draft-9: 1003.2.getopt

Date: Mon, 8 Jul 85 12:51:54 EDT
From: Keith Bostic <seismo!keith>
To: ut-sally!std-unix
Subject: Public domain version of getopt(3)


John, you posted Henry Spencer's original version of getopt (message
#11, I believe) unless you've posted two versions.  [ I've posted only
one before, which was Henry Spencer's.  -mod ] The reason that I
reimplemented after that version was:

    1: his used the stdio library printf call, thus forcing the
        loading of some large routines even if your program
        didn't need them.
    2: his didn't have the same error messages that the SysV one had.
    3: his didn't use certain external variables (optarg,
        opterr, optind and optopt) that the SysV one had.

Obviously, #3 is the real reason, the others were bug fixes if
anything.  In any case, the version I sent to you (it's included below
if you've lost it) [ I have the one from net.sources, but I thought it
best to get whatever your latest version is.  If you mailed me one
before, it never arrived, possibly because my sun crashed about that
time.  -mod ] is the version that will be released with 4.3BSD and, as
far as I know, is totally compatible with SysV.  [ How about sending
it to mod.sources, as well?  -mod ]

--keith
======================================================================

#include <stdio.h>

/*
 * this is a public domain version of getopt(3).
 * bugs, fixes to:
 *        Keith Bostic
 *            ARPA: keith@seismo
 *            UUCP: seismo!keith
 */

/*
 * get option letter from argument vector
 */
int    opterr = 1,        /* useless, never set or used */
    optind = 1,        /* index into parent argv vector */
    optopt;            /* character checked for validity */
char    *optarg;        /* argument associated with option */

#define BADCH    (int)'?'
#define EMSG    ""
#define tell(s)    fputs(*nargv,stderr);fputs(s,stderr); \
        fputc(optopt,stderr);fputc('\n',stderr);return(BADCH);

getopt(nargc,nargv,ostr)
int    nargc;
char    **nargv,
    *ostr;
{
    static char    *place = EMSG;    /* option letter processing */
    register char    *oli;        /* option letter list index */
    char    *index();

    if(!*place) {            /* update scanning pointer */
        if(optind >= nargc || *(place = nargv[optind]) != '-' || !*++place) return(EOF);
        if (*place == '-') {    /* found "--" */
            ++optind;
            return(EOF);
        }
    }                /* option letter okay? */
    if ((optopt = (int)*place++) == (int)':' || !(oli = index(ostr,optopt))) {
        if(!*place) ++optind;
        tell(": illegal option -- ");
    }
    if (*++oli != ':') {        /* don't need argument */
        optarg = NULL;
        if (!*place) ++optind;
    }
    else {                /* need an argument */
        if (*place) optarg = place;    /* no white space */
        else if (nargc <= ++optind) {    /* no arg */
            place = EMSG;
            tell(": option requires an argument -- ");
        }
         else optarg = nargv[optind];    /* white space */
        place = EMSG;
        ++optind;
    }
    return(optopt);            /* dump back option letter */
}

--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 14

From jsq  Mon Jul  8 15:00:21 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: guest moderator
Message-Id: <[e-mail]>
Date: 8 Jul 85 20:00:16 GMT
Reply-To: std-unix-request@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 17
Approved: [e-mail]
Draft-9: mod.std.unix

From: John Quarterman (moderator) <std-unix-request@ut-sally>

Since I'm going to be out of town from Tuesday, 9 July through
Sunday, 14 July, there will be a guest moderator this week.
He's John B. Chambers of MCC, who was co-author of the
"UNIX System V and 4.1C BSD" paper which was a main reason
the USENIX board picked on me, so it's only appropriate that
he have to pay, er, *help*, too.

Mail to ut-sally!std-unix and ut-sally!std-unix-request will
go to both me and jbc.  Mail to ut-sally!jsq will just sit around
in my mailbox until I get back, so it's best to mail to one
of the above aliases.
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 15

From [e-mail] Sun Jul 14 19:54:12 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:19 GMT
References: <[e-mail]>
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 35
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: getopts (command line arguments) continued

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

Date: Mon, 8 Jul 85 14:41:54 PDT
From: UCLA Computer Club <[e-mail]>
Subject: Re: command line arguments

Regarding getopts and the 'all arguments are proceded by a "-"':
What about arguments that can be on/off switches, or can be positive or
negative numbers? In other words, what is wrong with allowing '+' as an
indicator of arguments? There are some commands that use it already.

Incidently, what happens with getopts if the command line was
command -n -30
and:
Option n is fetched
option 3 is fetched
option 0 is fetched

(No well written program would do all this, but essentially, what happens
if an argument looks like a flag? Or have you never grep'ed for a string
beginning with -?)

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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 16

From [e-mail] Sun Jul 14 19:55:00 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:26 GMT
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 51
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: command line arguments continued

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

Date: 8 Jul 85 23:23:03 CDT (Mon)
From: ihnp4!utzoo![e-mail]
Subject: Re: command line arguments

> I doubt the necessity and even the wisdom of seperating an argument from
> the option by whitespace.

As I recall it, the AT&T standard does it this way on the grounds of
readability, not necessity.  The "-t/dev/tty" example is an easy one
to pick out, but what about "-dfaglop"?  Which of those letters are
options, and which are an option argument?

> I also dislike the blackballing of multicharacter options.

Unfortunately, they are seriously incompatible with one-character options
and option bundling, both of which are too firmly entrenched to be changed
at this late date.  There were earlier attempts within AT&T to change
the world by legislating a different way of doing things; you don't hear
about them because they were failures.  People ignored them.  Getopt and
the option standard have the virtue of being pretty much compatible with
the bulk of present practice, which makes it far more likely that they
will be *adopted*.

> As for multicharater options: do you intend to kill "tail -30"? Since
> changing the number of lines is the most common case what's the problem?
> At any rate you should allow a simple '-nnn' for a high-usage.

The AT&T people admit that existing high-usage programs cannot be changed
retroactively.  This is a blemish rather than a disaster.  I tend to agree
that "-nnn" would be nice to have, but am not excited enough about it to
fight a battle over it.

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



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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 17

From [e-mail] Sun Jul 14 20:36:16 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: What to do about extraneous arguments?
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:42 GMT
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 38
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: command line arguments continued

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

From: ihnp4!tektronix![e-mail]
Date: Saturday, 13 Jul 85 18:43:47 PDT
Subject: What to do about extraneous arguments?

Another aspect of command arguments is: after all the necessary arguments
have been processed, what if some are left?

Some commands process the whole list, and are intended to do so (e.g.
ls(1)).  Others (e.g. diff(1), cmp(1)) only work on a specific number
of arguments.

Common practice seems to be to ignore extraneous arguments.  A user here
has requested that cmp(1) be modified to generate a diagnostic if more
than 2 filenames are provided.  This might be helpful when using wildcards
for filenames, as in:

    cmp foo* fum*

If there is more than one file matching 'foo*' and you don't realize it,
the results are not what you expect.  Comments?

tektronix!rdoty


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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 18

From [e-mail] Sun Jul 14 20:37:12 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: getopt bundling brouhaha
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:32 GMT
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 37
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: getopt and command line arguments continued

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

Date: Wed, 10 Jul 85 09:53:45 EDT
From: seismo!elsie![e-mail]
Subject: getopt bundling brouhaha

Why all this brouhaha over whether or not getopt should allow option arguments
to be bundled with option names?  Let each user decide! People who wanted to
bundle could place commands such as

    GETOPT=b
    export GETOPT

in their login command files; getopt could check the GETOPT environment
variable to see if it contained a 'b' and allow bundling if it did.

This method could be used to give users control over other aspects of
getopt's behavior (whether to be sensitive to the case of option names;
whether to recognize options anywhere on the command line; and so on).
--
    UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie![e-mail]
    DEC, VAX and Elsie are Digital Equipment and Borden trademarks



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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 19

From [e-mail] Sun Jul 14 20:38:21 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: curses, terminfo, and termcap
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:29 GMT
References: <[e-mail]>, <[e-mail]>
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 46
Approved: [e-mail]
Draft-9: curses

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: curses, terminfo, termcap

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

Date: 10 Jul 85 00:15:09 CDT (Wed)
From: ihnp4!utzoo![e-mail]
Subject: Re: curses, terminfo, and termcap

> What I think is important about curses is not the code that implements
> it (although this code was hard and it shouldn't have to be done more
> than once) but the interface between the program and the package.
> Curses is intended as a way to write portable screen oriented applications.
> ...
> I personally would like to see curses (or some appripriate subset) become
> part of the C standard, along with Standard I/O.  However, it appears that
> the committee is not planning to do this.  Lacking this, I would like to
> see it become part of a UNIX standard.

One might argue (and on Mondays, Wednesdays, and Fridays I would) that a
standard screen-handling package ought to be oriented towards display of
text rather than video games.  Unless I have missed something -- I am not
all that familiar with curses -- when I insert a line in the middle of my
"screen", curses essentially has to rediscover this by comparing characters.
This seems silly; surely higher-level primitives would be better for most
situations.  (Rogue is a different story, of course.)

Something like the "FastAlpha" package described by HP a couple of Usenixes
ago would be a much better match to text-oriented screen handling, which I
would guess describes the majority of non-game curses applications.  Alas,
curses is already pretty well established; it may be too late to change.

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



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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 20

From [e-mail] Sun Jul 14 20:46:03 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re;  bostic's getopt
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:36 GMT
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 145
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: getopt and command line arguments continued

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

Date: Wed, 10 Jul 85 15:14:05 edt
From: harvard!talcott!wjh12!mirror![e-mail] (Rich Salz)
Subject: Re;  bostic's getopt


I have modified Keith Bostic's getopt code to make three changes:
    1.  my own (warped) esthetics.
    2.  add non-stdio code compile-time flag.
    3.  add trivial code to handle the opterr variable.
This last change is the most important; opterr, if set to 0 in
mainline code, suppresses printing all error messages.

i also cleaned up a couple of things.

feel free to re-post this to std-unix, or even {net,mod}.sourceds
if you think it will be worthwhile...

--
Rich $alz    {mit-eddie, ihnp4!inmet, wjh12, cca, datacube} !mirror!rs
Mirror Systems    2067 Massachusetts Ave.
617-661-0777    Cambridge, MA, 02140

/*
**  This is a public domain version of getopt(3).
**  Bugs, fixes to:
**        Keith Bostic
**            ARPA: keith@seismo
**            UUCP: seismo!keith
**  Added NO_STDIO, opterr handling, Rich $alz (mirror!rs).
*/

#include <stdio.h>

/*
**  Error macro.  Maybe we want stdio, maybe we don't.
**  The (undocumented?) variable opterr tells us whether or not
**  to print errors.
*/

#ifdef    NO_STDIO

#define tell(s)                                \
    if (opterr)                            \
    {                                \
        char    ebuf[2];                    \
        (void)write(2, nargv, (unsigned int)strlen(nargv));        \
        (void)write(2, s, (unsigned int)strlen(s));            \
        ebuf[0] = optopt;                        \
        ebuf[1] = '\n';                        \
        (void)write(2, ebuf, 2);                    \
    }

#else

#define tell(s)                                \
    if (opterr)                            \
        (void)fputs(*nargv, stderr),                \
        (void)fputs(s,stderr),                    \
        (void)fputc(optopt, stderr),                \
        (void)fputc('\n', stderr)

#endif


/* Global variables. */
static char     EMSG[] = "";
int         opterr = 1;        /* undocumented error-suppressor*/
int         optind = 1,        /* index into argv vector    */
int         optopt;        /* char checked for validity    */
char        *optarg;        /* arg associated with option    */


/* Linked in later. */
extern char    *index();        /* This may be strchr        */


getopt(nargc, nargv, ostr)
    int              nargc;
    char        **nargv;
    char         *ostr;
{
    static char         *place = EMSG;    /* option letter processing    */
    register char     *oli;        /* option letter list index    */

    if (!*place)            /* update scanning pointer    */
    {
    if (optind >= nargc || *(place = nargv[optind]) != '-' || !*++place)
        return(EOF);
    if (*place == '-')        /* found "--"            */
    {
        optind++;
        return(EOF);
    }
    }
    /* option letter okay? */
    if ((optopt = *place++) == ':' || (oli = index(ostr, optopt)) == NULL)
    {
    if (!*place)
        optind++;
    tell(": illegal option -- ");
    goto Bad;
    }
    if (*++oli != ':')            /* don't need argument        */
    {
    optarg = NULL;
    if (!*place)
        optind++;
    }
    else                /* need an argument        */
    {
    if (*place)
        optarg = place;        /* no white space        */
    else
        if (nargc <= ++optind)
        {
        place = EMSG;
        tell(": option requires an argument -- ");
        goto Bad;
        }
        else
        optarg = nargv[optind];    /* white space            */
    place = EMSG;
    optind++;
    }
    return(optopt);            /* dump back option letter    */
Bad:
    return('?');
}



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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 21

From [e-mail] Sun Jul 14 20:46:59 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: getopt(3) (again...)
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:38 GMT
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 87
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: getopt (command line arguments) continued

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

Date: Thu, 11 Jul 85 14:07:41 EDT
From: Keith Bostic <[e-mail]>
Subject: getopt(3) (again...)


Just when I thought it was safe to read my mail...

> i made a couple of changes.  esthetics, absolutely no stdio if
> desired, and the opterr variable.  here's my revision:

I'm getting pretty tired of this whole issue -- in fact, I kept starting
to reply to your mail and then deciding not to, figuring that if I didn't
maybe the whole thing would die off.  *sigh*  Well, my friend, here's
a reply.  The content is simple.  You are wrong.  Pure-d, absolutely,
wrong.

Point by point:

esthetics:
    Esthetics are all very well and good, and we could argue for the next
several days as to whether a goto can be considered esthetical, or whether
indentation should be 4 characters or 8, or whether "void" is really a good
idea, or if "index()" *really* needs to be declared outside of the local
routine, etc. etc. until the cows return from pasture.  On the other hand,
4.3BSD is going to use my code.  Since it works, I see no value in making
the wheel ever so slightly rounder, if, in fact, you managed to do so.  I do
not wish to spend the rest of my life figuring out that some getopt really
does work.  I would like to assume that the one that comes with 4.3 does work
and I can therefore turn my attention to other parts of an ailing program,
after doing a very brief "diff" of the two modules.  The world does not need
another getopt.  When I re-wrote the one I did, it did.

absolutely no stdio if desired:
    Well, for an error condition that's going to happen once before the
program exits, it's gonna be faster.  You saved about 2 routine calls, near
as I can figure.  You didn't save any library space, which is why I changed
the original fprintf() calls to fputs() calls.

the opterr variable:
    The other two items, I could live with.  Here, on the other hand,
you have single-handedly created a real pain in the ass in terms of
portability.

Scenario #1:
    Bell Labs doesn't ever decide to use opterr.  Fine and dandy,
    except that people who use your new flag will find that their
    code will not run as expected on USG UNIX.

Scenario #2:
    USG uses the flag, but makes it backward compatible.  Well, little
    problem here, BSD code will now not run on USG machines which is
    the situation we had before we wrote the damn thing.

Scenario #3:
    USG uses the flag, but doesn't make it backward compatible.
    Unlikely, but possible.  Well, we change getopt(3) to be like
    Bell, breaking all of the code that has been written to use your
    new flag, or, of course, we could just diverge the two systems
    again.  Fun, fun!

As it is (or was, before this new edition) we just change to use USG's
new opterr behaviors and go on as before, unless they don't make it
backward compatible, in which case the entire UNIX world is in the same
boat.

I would have been much more amenable to changes two months ago; if you
can get Mike Karels to use your version rather than mine, I will again
be much more amenable to changes.  Well, with the exception of your use
of opterr.

--keith


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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 22

From [e-mail] Sun Jul 14 20:48:02 1985
Path: ut-sally!mcc-db!jbc
From: mcc-db!jbc (John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: command line arguments
Message-Id: <[e-mail]>
Date: 14 Jul 85 23:56:22 GMT
Reply-To: std-unix-request@ut-sally
Organization: MCC (Austin, TX)
Lines: 155
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Chambers (guest moderator) <ut-sally!std-unix>

Topic: command line arguments

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

Date: Mon, 8 Jul 85 00:52:46 pdt
From: nsc!turtlevax![e-mail] (Ken Turkowski)
Subject: Re: command line arguments

Someone suggested that parsing arguments in shell scripts was difficult.
I include the following shell scripts, one for the Bourne shell and one
for the C-shell, which parse arguments of the form:
    -v -O -o outfile file1 file2 file3
as well as
    -vOooutfile file1 file2 file3

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

# This is a shell archive.  Remove anything before this line, then
# unpack it by saving it in a file and typing "sh file".  (Files
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
# std.sh std.csh

echo x - std.sh
cat > "std.sh" << '//E*O*F std.sh//'
#! /bin/sh
PATH=/usr/ucb:/bin:/usr/bin:/usr/local/bin
verbose=false
files=
trap 'rm $temp_files; exit' 0 1 2
for arg            # Look for flags
do    while true
    do    case $arg in
        -\?|-help) cat << EOF
This shell script accepts the arguments:
    -v        Verbose
    -o <outfile>    Output directed to <outfile> instead of default
    <file> ...    Files to be processed
It parses the arguments and prints the results of the parse.
EOF
            exit ;;
        -)    echo NULL FLAG; break ;;
        -v*)    verbose=true ;;
        -o*)    outfile=`expr $arg : '-.\(.*\)'` || outfile=UNKNOWN
            break ;;
        -*)    echo Unknown flag: \"$arg\"
            unkflag="$unkflag $arg"
            break ;;
        *)    case UNKNOWN in
            $outfile)    outfile=$arg ;;
            *)        files="$files $arg" ;;
            esac
            break ;;
        esac
        arg=-`expr "$arg" : '-.\(.*\)'` || break
    done
done

set x $files
shift
for arg        # input file processing template
do
    echo processing file \"$arg\"
done

# The following is just for testing this standard script
echo '
Argument' analysis to $0:
echo Flags: -v = $verbose, -o = \"$outfile\"
echo Unknown flags: $unkflag
echo Files: $files
//E*O*F std.sh//

echo x - std.csh
cat > "std.csh" << '//E*O*F std.csh//'
#! /bin/csh -f
unalias *
set path = (/usr/ucb /bin /usr/bin /usr/local/bin)
unset Verbose
set temp_files=
set outfile
set unkflag
set files
onintr cleanup
foreach argument ( $*:q )
    while ( 1 )
        switch ( "$argument" )
        case -[?]:
        case -help:
        cat << EOF
This shell script take the arguments:
    -v        Verbose
    -o <outfile>    Change output file to <outfile> instead of the default.
    -? or -help    Prints this help message
    <file> ...    Input files
It parses them and prints the result of the parse.
EOF
        exit
            case -:
                echo 'NULL FLAG'
                break
            case -v*:
        set Verbose
        breaksw
            case -o*:
                set outfile = `expr $argument : '-.\(.*\)'` || set outfile = UNKNOWN
                break
            case -*:
                echo Unknown flag: \""$argument"\"
                set unkflag = "$unkflag $argument"
                break
            case *:
                switch ( UNKNOWN )
                    case "$outfile":
            set outfile = $argument
            breaksw
                    default:
            set files = "$files $argument"
                endsw
                break
        endsw
        set argument = -`expr "$argument" : '-.\(.*\)'` || break
    end
end

# The following is just for testing this standard script
echo ' Argument analysis to' $0 ':'
echo Flags: -v = ${?Verbose}, -o = \"$outfile\"
echo Unknown flags: $unkflag
echo Files: $files

cleanup:
    rm $temp_files
exit
//E*O*F std.csh//

exit 0
--

Ken Turkowski @ CADLINC, Menlo Park, CA
UUCP: {amd,decwrl,hplabs,nsc,seismo,spar}!turtlevax!ken
ARPA: turtlevax![e-mail]


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

--

John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
{ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, [e-mail], [e-mail]

Volume-Number: Volume 1, Number 23

From jsq  Tue Jul 16 14:35:27 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: a bit more on getopt
Message-Id: <[e-mail]>
Date: 16 Jul 85 19:35:20 GMT
References: <[e-mail]>
Reply-To: std-unix@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 116
Keywords: option parsing, command line arguments
Approved: [e-mail]
Summary: we've pretty much covered this subject
Draft-9: 1003.2.getopt

From: John Quarterman <[e-mail]> (moderator)
Topic: command line arguments (getopt)

There's getting to be a bit of repetition and a certain amount of
flamage on this subject.  Several things seem clear to me, at least:

1) Keith Bostic's getopt is the de facto standard public domain getopt
    because a) it implements everything the System V one does,
    down to specific error messages and global variables, and
    b) it's going to be in 4.3BSD.  It also may or may not be
    more efficient or smaller when seen in perspective.
2) Henry Spencer's getopt, in the version that I posted that Ian Darwin
    sent, is just about as good, since its earlier bug is fixed,
    though it lacks some undocumented System V features which
    Bostic's includes.
3) There are numerous minor functional changes which might be desirable
    for one reason or another, but they would *be* changes, and are
    not in the "standard" getopt.  The existing getopt is good
    enough for most purposes, and is widely available:  there is
    no need for another implementation.

While these are my personal opinions, they appear to agree with
those of the two getopt authors mentioned above.  Since I have
to go by something in moderating the newsgroup, I will discourage
from now on submissions which merely argue the above points again.
In other words, let's try to think of something new to say, or
go on to something else.


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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 15 Jul 85 16:10:12 CDT (Mon)
To: ihnp4!ut-sally!std-unix
Subject: Re: What to do about extraneous arguments?
References: <[e-mail]>

> Common practice seems to be to ignore extraneous arguments.  A user here
> has requested that cmp(1) be modified to generate a diagnostic if more
> than 2 filenames are provided.  ...

The standard program skeleton for using getopt(3) includes, after the
big while-switch for the options, the code:

    if (errflg) {
        fprintf(stderr, "Usage: ...\n");
        exit(2);
    }

It's pretty simple to change that "if (errflg) {" to something like
"if (errflg || optind+2 != argc) {".  This is what we do in such cases.
Easy and effective.
                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,linus,decvax}!utzoo!henry

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 15 Jul 85 16:09:35 CDT (Mon)
To: ihnp4!ut-sally!std-unix
Subject: Re: command line arguments
References: <[e-mail]>, <[e-mail]>

> Regarding getopts and the 'all arguments are proceded by a "-"':
> What about arguments that can be on/off switches, or can be positive or
> negative numbers? In other words, what is wrong with allowing '+' as an
> indicator of arguments? There are some commands that use it already.

The AT&T people considered this.  (It would be nice to see a posting of
the AT&T paper, in fact, if someone has it machine-readable [I don't]
[ I don't either, but if someone would mail it to me, I would post it
(if it's reasonably short) -mod ]; it would shorten this discussion
considerably.)  They thought the following were reasonable criteria for
accepting + :

1. Clear, simple, well-defined rules for when + should be used.
2. Rules should be applicable to more than just a few atypical commands.
3. Use of + should complement, not conflict with, the general use of -
    as an option marker (*not* as a "negation" indicator, note).

Their observations were that the existing uses of + meet none of these
criteria, that compatibility would prevent cleaning up existing uses,
and that criterion #3 seemed impossible to satisfy.  So, no +.

> Incidently, what happens with getopts if the command line was
> command -n -30
> and:
> Option n is fetched
> option 3 is fetched
> option 0 is fetched
>
> (No well written program would do all this, but essentially, what happens
> if an argument looks like a flag? Or have you never grep'ed for a string
> beginning with -?)

If -n is an option taking a value, then the next argument is its value,
even if it happens to have a - on the front.  The apparent ambiguity is
resolved by knowing which options take values and which don't.

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

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

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:    ut-sally!std-unix
Comments about the newsgroup to:    ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 24

From jsq  Tue Jul 16 14:44:04 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: curses, terminfo, and termcap
Message-Id: <[e-mail]>
Date: 16 Jul 85 19:43:50 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: std-unix@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 23
Approved: [e-mail]
Summary: it's too big to post to this newsgroup or to mail
Draft-9: curses

From: John Quarterman (moderator) <[e-mail]>

Several people have asked by mail if I could repost the public domain terminfo
and curses or mail it to them.  Unfortunately, I cannot:  it's much too big
to post to a discussion newsgroup like this, or to mail (at least from
ut-sally:  our phone bills are rather amazing already).  The best thing
to do is probably to write to the moderator of mod.sources <genrad!john>
and see what arrangements have been made about getting back issues of
mod.sources.


The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:    ut-sally!std-unix
Comments about the newsgroup to:    ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 25

From jsq  Tue Jul 16 15:00:58 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Scope and Purpose of IEEE P1003 "UNIX Standards" Committee
Message-Id: <[e-mail]>
Date: 16 Jul 85 20:00:38 GMT
Reply-To: std-unix@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 84
Approved: [e-mail]
Draft-9: 1.0

From: John Quarterman (moderator) <[e-mail]>
Topic: IEEE P1003 "UNIX Standards" committee statement of scope and purpose

I've received the following from the chair of the committee for posting.


A.003.2
15JAN85
           Scope and Purpose of the IEEE P1003 Working Group

"To define a standard operating system interface and environment based
on the  UNIX Operating System documentation to support application
portability at the source level. (UNIX is a trademark of Bell Labs)"

This effort entails three major components:

1.  Definitions - Terminology and objects referred to in the document.
    In the case of objects, the structure, operations that modify these,
    and the effects of these operations need to be documented as well.
    (Sample Term:  Pipe, Sample Object:  File Descriptor)

2.  Systems Interface and Subroutines (C-Language Binding)
    This area includes:

    A.  The range of interface & subroutines in the /usr/group document
    B.  IOCTL/TermIO
    C.  IFDEF Specifications
    D.  Real Time (Contiguous files, synchronization, shared data, priority
        scheduling, etc.)
    E.  Device interface, including Termcaps/TermIO
    F.  Job Control, Windowing
    G.  Network Interface (but not Protocol)
    H.  Distributed Systems
    I.  Device Drivers
    J.  Error Handling & Recovery

3.  User interface issues, including:

    A.  Shell, Command Set, Syntax
    B.  Portability - Media/Formats
    C.  Error Handling & Recovery

In all of these areas, consideration will be given to defining the impact on
security, international usage (language and character sets, etc.), and
application needs such as transaction processing.

The following areas may require review and commentary, perhaps even revisions
and updates, but are outside of the scope of the current effort:  Network
Protocols, Graphics, DBMS, Record I/O.

Two areas are explicitly outside of the scope of the group:  Binary compati-
bility/exchange of software in executable form, and the end-user interface
(where ease-of-use is a critical issue).

Target "consumers" of the documents are:  Systems implementations (including
AT&T Licensees, those developing compatible systems, and those implementing
"hosted" systems), and application implementors - for areas 1 and 2.  With
Area 3, multivendor systems integrators and shell users are also identified
as document consumers.

All of these efforts will not occur at once.  The initial document for
balloting will be based on Section 1 and 2-A and B above.  As this goes
through the balloting process, additional areas in 2 and 3 will be readied
for balloting.  At this point, it is not clear if this will represent separate
revisions of a common document, separate "chapters" or "modules" of a common
document, or separate standards documents.

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

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:    ut-sally!std-unix
Comments about the newsgroup to:    ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.

The newsgroup is gatewayed to an ARPA Internet mailing list, accessible as
[e-mail] or [e-mail].
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 26

From jsq  Wed Jul 17 09:02:27 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: curses, terminfo, and termcap
Message-Id: <[e-mail]>
Date: 17 Jul 85 14:02:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (John Quarterman)
Organization: U. Texas CS Dept., Austin, Texas
Lines: 73
Approved: [e-mail]
Summary: how to get Pavel Curtis' implementation
Draft-9: curses

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: curses, terminfo, and termcap

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

From: harvard!panda!genrad!john (John P. Nelson)
Date: Wed, 17 Jul 85 09:23:12 edt
To: panda!talcott!harvard!seismo!ut-sally!jsq
Subject: Re: curses, terminfo, and termcap
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: GenRad, Inc., Bolton, Mass.


Please post this to mod.std.unix, since you have recommended that your
readership contact me directly.

  John P. Nelson (decvax!genrad!john) [moderator, mod.sources]

First, if you have access to any of the "standard" UNIX versions of curses,
you have got a better version than this one.  About the only thing that
recommends Pavel Curtis' version of curses is that it is public domain.
(Of course, that is pretty significant!) The terminfo implementation seems
to fairly solid, however.


For large distributions (such as the Pavel Curtis' terminfo/curses - 11 shar
format modules plus one more with updates) I try to discourage direct mailing
especially when the target site is several uucp hops away.  That generally
leaves two alternatives:  1. Send a tape in a self-addressed, stamped mailer.
I will put the distribution onto tape in tar, 1600 bpi format.  If you do
this, then make sure you include a note describing what you want put onto the
tape (Public Domain Terminfo/Curses package)  2.  I can send you the info for
our site's "sources" uucp login.  This uucp login is limited to transferring
to and from a single "sources" directory.  I am not making this login public
knowledge, because we cannot support any large level of traffic.

I am willing to entertain other suggestions.

John P. Nelson (decvax!genrad!john) [moderator, mod.sources]
GenRad   M.S. 96
37 Great Road
Bolton, MA 01740

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

Date: Wed, 17 Jul 85 08:31:57 cdt
From: [e-mail] (John Quarterman)
Subject: Re:  PD terminfo, curses, etc.

If you are on the ARPA Internet, you can get it by anonymous FTP
(login anonymous, password guest) from ut-sally.ARPA from the directory
~ftp/pub/curses, where the files named 1 through 11 correspond to the
pieces posted on mod.sources.  There doesn't seem to be a standard ARPA
Internet repository for mod.sources.

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

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:    ut-sally!std-unix
Comments about the newsgroup to:    ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.

The newsgroup is gatewayed to an ARPA Internet mailing list, accessible as
[e-mail] or [e-mail].
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 27

From jsq  Thu Jul 18 10:21:26 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: standardized error messages
Message-Id: <[e-mail]>
Date: 18 Jul 85 15:10:09 GMT
Reply-To: std-unix@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 36
Approved: [e-mail]
Draft-9: 2.5

From: Mike Trachtman  <[e-mail]>
Date: Thu, 18 Jul 85 13:03:51 -0200
To: [e-mail]
Subject: standardized error messages

Is any thought being given to having the compilers, grep, etc.
give error messages in a standard form, so
that programs will be able to parse them.

This is good for many things, in particular emacs make error parsing,
but other uses are also possible.
Mike

                                Mike Trachtman
My address:

        wizard@wisdom                           (BITNET)
        [e-mail]        (ARPA/CSNET)
        wizard%wisdom.bitnet@berkley            (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
        ...!decvax!humus!wisdom!wizard          (UUCP)

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

This moderated newsgroup, mod.std.unix, is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003 Committee.
The newsgroup is also gatewayed to an ARPA Internet mailing list.

Submissions to:    ut-sally!std-unix      or [e-mail]
Comments to:    ut-sally!std-unix-request or [e-mail]
Permission to post to the newsgroup is assumed for mail to std-unix,
but not for mail to std-unix-request, nor for mail to my personal addresses.
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 28

From jsq  Thu Jul 18 10:54:08 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt
Message-Id: <[e-mail]>
Date: 18 Jul 85 15:53:58 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: std-unix@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 179
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Quarterman <[e-mail]> (moderator)
Topic: command line arguments (getopt)

> There's getting to be a bit of repetition and a certain amount of
> flamage on this subject.  Several things seem clear to me, at least:
>
> 1) Keith Bostic's getopt is the de facto standard public domain getopt

Well, it seems I may have been hasty to state that.  More follows.

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

Date: Tue, 16 Jul 85 19:10:43 edt
From: ihnp4!cmcl2!edler (Jan Edler)
To: ihnp4!ut-sally!std-unix
Subject: another getopt

Another important public-domain implementation of getopt(3)
is the one from AT&T available from the UNIX system toolchest.

    Jan Edler
    New York University
    ihnp4!cmcl2!edler
    [e-mail]

[ The toolchest number is 201-522-6900, where you can log in as guest.
Getopt is listed as for $0.00, though there is evidently a $100.00
registration fee, a transfer fee ($10?) and tax.

If the source for this was actually published in the Dallas /usr/group
meeting proceedings, could someone who has them please type it in and
submit it to this newsgroup?  I could assume that the getopt in my
System V sources is the same as that published at Dallas and post it,
but it might not be.  -mod ]

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

From: seismo!cbosgd!pegasus!hansen (Tony Hansen)
Date: Thu, 18 Jul 85 01:29:42 EDT
To: ut-sally!std-unix, cbosgd!seismo!keith
Subject: Re: getopt(3) (again...)
In-Reply-To: <[e-mail]>
Organization: AT&T-IS Labs, Lincroft, NJ

In article <[e-mail]> you write:
>Date: Thu, 11 Jul 85 14:07:41 EDT
>From: Keith Bostic <[e-mail]>
>Subject: getopt(3) (again...)
>
>Just when I thought it was safe to read my mail...
>
>> From: harvard!talcott!wjh12!mirror![e-mail] (Rich Salz)
>>
>> i made a couple of changes.  esthetics, absolutely no stdio if
>> desired, and the opterr variable.  here's my revision:
>
>I'm getting pretty tired of this whole issue -- in fact, I kept starting
>to reply to your mail and then deciding not to, figuring that if I didn't
>maybe the whole thing would die off.  *sigh*  Well, my friend, here's
>a reply.  The content is simple.  You are wrong.  Pure-d, absolutely,
>wrong.

Actually, the recently posted rewrite by Rich Salz is closer to AT&T's code
than is yours and his is more accurate.

>Point by point:
>
    ... (no comment on aesthetics)
>
>absolutely no stdio if desired:
>    Well, for an error condition that's going to happen once before the
>program exits, it's gonna be faster.  You saved about 2 routine calls, near
>as I can figure.  You didn't save any library space, which is why I changed
>the original fprintf() calls to fputs() calls.

Actually this is important in some applications which do not already use
stdio and do not wish to load in the 10k or so overhead that using stdio
incurs. AT&T's code does not use stdio in getopt(3).

>the opterr variable:
>    The other two items, I could live with.  Here, on the other hand,
>you have single-handedly created a real pain in the ass in terms of
>portability.
>
>Scenario #1:
>    Bell Labs doesn't ever decide to use opterr.  Fine and dandy,
>    except that people who use your new flag will find that their
>    code will not run as expected on USG UNIX.

Sigh. Here's the real crux of the matter: USG UNIX already has and uses
opterr exactly as used by Rich's code. It is poorly documented,
unfortunately.

>I would have been much more amenable to changes two months ago; if you
>can get Mike Karels to use your version rather than mine, I will again
>be much more amenable to changes.  Well, with the exception of your use
>of opterr.

I thought UCB had a System V license. Couldn't they have checked your
public-domain version against the code that was in the System V source
easily enough for incompatibilities?

In fact, why go with yours or Rich's version at all and not use the
public-domain version that AT&T published at January's Uni-Forum in Dallas?
That would have gotten rid of all thought of incompatiblity!
[ They may not have been aware of it:  few other people seem to be.
Perhaps you could type it in and submit it to the newsgroup? -mod ]

>  The world does not need another getopt.

You're right. Why'd you bother adding one? :-)

>    ..., or, of course, we could just diverge the two systems
>    again.  Fun, fun!

I hope 4.3BSD picks up AT&T's public-domain version of getopt(3) for use
rather than creating yet-another branching of ways by using yours, Keith, or
Rich's.  [ You could submit the AT&T source to Berkeley as a bug fix.  -mod ]

                    Tony Hansen
                    ihnp4!pegasus!hansen

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

From: Dave Berry <seismo!cstvax.ed.ac.uk!mcvax!db>
Date: Tue, 16 Jul 85 15:43:56 bst
To: ut-sally!std-unix
Subject: Command lines

It's probably way too late for this to be suggested, but the longer it's
left, the worse it will be.
How about completely revamping the unix command line syntax to be
    command {{-option ...} {file ...} ...}
with command names & option names being full words (e.g. remove, not rm)
and using command (and argument) completion a la VMS?  I used UNIX for three
years before using VMS, and I far prefer this approach to command line syntax
(though VMS filenames & DCL are appalling!).
    A couple of MMI articles I've read (in CACM I think) report evidence
that users far prefer command completion to cryptic abbreviations in the
UNIX tradition.
    The rest of UNIX is being dragged kicking & screaming into the
"real world" - I'd like to see this change happen too.

[ Command and file name completion has been added to the C shell in
several steps and posted to net.sources over the last couple of years.
4.3BSD will include both (made quite a bit more efficient) as an option
in the distributed C shell (according to what the Berkeley CSRG people
said at the 4BSD BOF at the Portland USENIX).  I don't know if such
has been done in any version of the Bourne or Korn shells.  -mod ]

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

From: [e-mail] (John Quarterman)
Date: Thu Jul 18 10:51:48 CDT 1985
To: ut-sally!std-unix
Subject: Re: Command lines

It seems to me that general command argument completion would have to
be implemented in each command, and would require each command to be
able to interact with terminals.  Doesn't seem worth it to me, but then
I've always thought argument completion to be one of TENEX/TOPS-20/VMS's
most annoying features.  Argument completion would also seem to rule
out multiple options in the same word, which is a bit of a compatibility
problem.

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

This moderated newsgroup, mod.std.unix, is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003 Committee.
The newsgroup is also gatewayed to an ARPA Internet mailing list.

Submissions to:    ut-sally!std-unix      or [e-mail]
Comments to:    ut-sally!std-unix-request or [e-mail]
Permission to post to the newsgroup is assumed for mail to std-unix,
but not for mail to std-unix-request, nor for mail to my personal addresses.
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 29

From jsq  Thu Jul 18 17:48:55 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt
Message-Id: <[e-mail]>
Date: 18 Jul 85 22:48:44 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: std-unix@ut-sally
Organization: U. Texas CS Dept., Austin, Texas
Lines: 82
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Quarterman (moderator) <[e-mail]>
Topic: still more on command line arguments (getopt)

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

From: seismo!nsc!idi!bene!luke!itkin (Steven List)
Date: Thu, 18 Jul 85 09:20:51 pdt
To: ut-sally.ARPA!std-unix
Subject: extraneous arguments
Organization: Benetics Corp, Mt. View, CA

>From: ihnp4!tektronix![e-mail]
>Date: Saturday, 13 Jul 85 18:43:47 PDT
>Subject: What to do about extraneous arguments?
>
>Another aspect of command arguments is: after all the necessary arguments
>have been processed, what if some are left?
>

I'm in agreement with tektronix!rdoty.  I believe no program should produce
unexpected results without some explanation.  In the case of programs
like cmp and diff, a diagnostic AND a nonzero exit status would seem to
be appropriate.  The diagnostic message would tend to satisfy checks on
the size of the output being nonzero, and the status would satisfy
status checks.

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

Date: Wed, 17 Jul 85 12:00:54 cdt
From: neuro1!baylor![e-mail] (Peter da Silva)
Subject: Re: Re: command line arguments
References: <[e-mail]>

> Date: Mon, 8 Jul 85 00:52:46 pdt
> From: nsc!turtlevax![e-mail] (Ken Turkowski)
> Subject: Re: command line arguments
>
> Someone suggested that parsing arguments in shell scripts was difficult.
> I include the following shell scripts, one for the Bourne shell and one
> for the C-shell, which parse arguments of the form:
>     -v -O -o outfile file1 file2 file3
> as well as
>     -vOooutfile file1 file2 file3
>

Sure, you can make shell scripts do almost anything. When I get a source with
that sort of stuff in it I generally rip it out & put up with weirdness. Why?
Well, our system is badly overloaded. Commands like that take 30 seconds to
a minute to start up!

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

Date: Wed, 17 Jul 85 12:04:53 cdt
From: neuro1!baylor![e-mail] (Peter da Silva)
Subject: Re: Re: command line arguments
References: <[e-mail]>

> > I doubt the necessity and even the wisdom of seperating an argument from
> > the option by whitespace.
>
> As I recall it, the AT&T standard does it this way on the grounds of
> readability, not necessity.  The "-t/dev/tty" example is an easy one
> to pick out, but what about "-dfaglop"?  Which of those letters are
> options, and which are an option argument?

OK, instead of forcing whitespace, how about requiring that there only be one
flag if you are going to do this sort of stuff? I have had shell scripts
totally broken by this requirement, and workarounds take up so much overhead
(yes, some people have systems smaller than vaxen) that it's not worth the
hassle.

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

This moderated newsgroup, mod.std.unix, and the corresponding ARPA Internet
mailing list, is for discussions of UNIX standards; specifically
the draft standard in progress by the IEEE P1003 Committee.
Submissions to:    ut-sally!std-unix      or [e-mail]
Comments to:    ut-sally!std-unix-request or [e-mail]
--

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  [e-mail], soon to be [e-mail]

Volume-Number: Volume 1, Number 30

From jsq  Thu Jul 18 20:32:27 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt
Message-Id: <[e-mail]>
Date: 19 Jul 85 01:32:22 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 34
Approved: [e-mail]
Draft-9: 1003.2.getopt

Date: Thu, 18 Jul 85 20:29:59 EDT
From: Keith Bostic <seismo!keith>
To: /dev/null
Subject: Re: getopt(3) (again...)
Cc: pegasus!hansen, ut-sally!std-unix

> Actually, the recently posted rewrite by Rich Salz is closer to AT&T's code
> than is yours and his is more accurate.

You're right, I apologize.  I totally missed the USG use of opterr and have
updated my code appropriately.  I am currently trying to get 4.3 to use
the correct code.

> Actually this is important in some applications which do not already use
> stdio and do not wish to load in the 10k or so overhead that using stdio
> incurs. AT&T's code does not use stdio in getopt(3).

Not true.  The size difference between:

    main() { puts("foo"); }
and
    main() { write(0,"foo",3); }

is exactly zero.

> In fact, why go with yours or Rich's version at all and not use the
> public-domain version that AT&T published at January's Uni-Forum in Dallas?
> That would have gotten rid of all thought of incompatiblity!

Amen, I didn't know about it in January or I would have said something when
Berkeley asked to use mine.

--keith


Volume-Number: Volume 1, Number 31

From jsq  Fri Jul 19 17:53:20 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt
Message-Id: <[e-mail]>
Date: 19 Jul 85 22:53:13 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 35
Approved: [e-mail]
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:     ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
Uucp-Routes: {ihnp4ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
Draft-9: 1003.2.getopt

From: seismo!BBN-LABS-B.ARPA!dan (Dan Franklin)
To: ut-sally!BBN-LABS-B.ARPA!std-unix
Subject: Re: a bit more on getopt
Date: 19 Jul 85 11:32:03 EDT (Fri)

>  > Actually this is important in some applications which do not already use
>  > stdio and do not wish to load in the 10k or so overhead that using stdio
>  > incurs. AT&T's code does not use stdio in getopt(3).
>
>  Not true.  The size difference between:
>
>      main() { puts("foo"); }
>  and
>      main() { write(0,"foo",3); }
>
>  is exactly zero.

Your second one-liner is still using stdio.  The difference between
       main() { puts("foo"); }
and
       main() { write(1, "foo", 3); }   exit(n) { _exit(n); }
on the other hand, is substantial, at least on my 4.2 VAX system (and, in my
experience, on other UNIX systems as well):

text    data    bss    dec    hex
2048    1024    15988    19060    4a74    stdio
1024    1024    0     2048     800    nostdio

1024       0    25988   17012           difference

The point about not using stdio in a library routine if it's not necessary
still stands.

    Dan Franklin


Volume-Number: Volume 1, Number 32

From jsq  Sun Jul 21 12:59:22 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt
Message-Id: <[e-mail]>
Date: 21 Jul 85 17:59:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 214
Approved: [e-mail]
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:     ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
Uucp-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
Draft-9: 1003.2.getopt

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: command line arguments (getopt)
    Is the AT&T getopt public domain, or just published?
    AT&T getopt(3) man page is inaccurate.
    Inclusion of stdio and size of programs.
    Options, white space, and shell scripts.
    Full word command names and arguments, and completion.

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 19 Jul 85 20:14:44 CDT (Fri)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Is AT&T getopt public-domain?  Not clear!

The document I have from the /usr/group standards meeting at Dallas
does *not* say that the AT&T getopt is being made public domain.  What
it says is:

    The [getopt] source code is being published by AT&T Bell
    Laboratories to encourage adherence to the command syntax
    standard and to satisfy requests from [everyone in sight].

Note that publishing something does *not* put it into the public domain
unless this is stated explicitly.  That may have been AT&T's intent, but
they didn't say it that way.  The document in question includes the AT&T
source, but I am reluctant to submit it to mod.std.unix until its status
is clarified.

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

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

Date: 20 Jul 85 11:03:28 EDT (Sat)
From: topaz!packard!nomad!ggr (Guy Riddle)
Subject: getopt: the Code vs. the Manual Page
To: ut-sally!std-unix
Cc: seismo!keith

I hope you haven't been modelling the 4.3 version of getopt(3) too
closely after the SVR2 manual page, for it lies about the details.

It states

    "Because optind is external, it is normally initialized to
    zero automatically before the first call to getopt."

Well, I'll grant that optind is external, but it is initialized to one.

Also, the claim that

    "This error message may be disabled by setting opterr
    to a non-zero value."

is also a lie.  Opterr is initialized to one, and to disable the error
message you must set it to zero.

        === Guy Riddle == AT&T Bell Laboratories, New Jersey ===

----------
|Rebuttal
|Corner
|
    Keith's assertion that

    > Not true.  The size difference between:
    >
    >     main() { puts("foo"); }
    > and
    >     main() { write(0,"foo",3); }
    >
    > is exactly zero.

    might be valid for 4.2, but it's not for SVR2, where the size of the
    puts(3) version is

        2432 + 456 + 2232 = 5120

    while the write(2) version is only

        128 + 12 + 0 = 140

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

From: ihnp4!decvax!borman (Dave Borman)
Date: Sat, 20 Jul 85 21:01:42 edt
To: decvax!ihnp4!ut-sally!std-unix
Subject: getopt(3) & stdio

>  >  > Actually this is important in some applications which do not already use
>  >  > stdio and do not wish to load in the 10k or so overhead that using stdio
>  >  > incurs. AT&T's code does not use stdio in getopt(3).
>  >
>  >  Not true.  The size difference between:
>  >
>  >      main() { puts("foo"); }
>  >  and
>  >      main() { write(0,"foo",3); }
>  >
>  >  is exactly zero.
>
>  Your second one-liner is still using stdio.  The difference between
>     main() { puts("foo"); }
>  and
>     main() { write(1, "foo", 3); }   exit(n) { _exit(n); }
>  on the other hand, is substantial, at least on my 4.2 VAX system (and, in my
>  experience, on other UNIX systems as well):

The first two examples are different, the puts() will pull in stdio and
the write() should not.  If you have to explicitly re-declare exit() to
avoid pulling in the stdio package, then your /lib/libc.a is mucked up.
exit() calls _cleanup, of which there are two copies in the /lib/libc.a.
The stdio package has a function _cleanup which flushes all the buffers.
There is also a dummy _cleanup routine (usually fakcu.s) which just
returns.  In /lib/libc.a, exit() must be archived after all the stdio
functions, and the dummy _cleanup must be archived after exit.  If you
have exit() before the stdio functions, then the reference to _cleanup
will pull in the whole stdio package.  If exit() is after the stdio
package and the dummy _cleanup after exit(), then if you don't reference
any stdio functions you will only pull in the dummy cleanup routine.

        -Dave Borman, Digital UNIX Engineering Group.
        decvax!borman

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

Date: Sat, 20 Jul 85 16:31:33 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!jsq
Subject: Re: a bit more on getopt

> Not true.  The size difference between:
>
>    main() { puts("foo"); }
> and
>    main() { write(0,"foo",3); }
>
> is exactly zero.

Only true on certain UNIX implementations.  Under Sun UNIX 2.0
(4.2BSD-based), there is a slight difference.  Under System V there is a
significant difference.  The problem is that 4.2BSD *always* drags in the
Standard I/O Library while System V doesn't.  4.xBSD could be changed, with
about 30 minutes work, to work the way System V does here, so the assumption
should be made that the Standard I/O Library does consume a nonzero amount
of code and data space.  (About 13788 bytes in one test I did; this doesn't
count buffers which are "malloc"ed when the first read/write is done.)

    Guy Harris

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 20 Jul 85 20:45:50 CDT (Sat)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Re: a bit more on getopt
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>

> > ...  The "-t/dev/tty" example is an easy one
> > to pick out, but what about "-dfaglop"?  Which of those letters are
> > options, and which are an option argument?
>
> OK, instead of forcing whitespace, how about requiring that there only be one
> flag if you are going to do this sort of stuff? I have had shell scripts
> totally broken by this requirement, and workarounds take up so much overhead
> (yes, some people have systems smaller than vaxen) that it's not worth the
> hassle.

We do a *lot* of shell programming, and our experience is that the
separating blank makes life easier, not harder.  Of course, we generally
use getopt(1) for the argument parsing, which makes life simpler.  utzoo
is a PDP11, by the way.

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

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 19 Jul 85 20:15:23 CDT (Fri)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Command lines

> It's probably way too late for this to be suggested, but the longer it's
> left, the worse it will be.
> How about completely revamping the unix command line syntax to be
>     command {{-option ...} {file ...} ...}
> with command names & option names being full words (e.g. remove, not rm)...

The AT&T command-line-syntax people have alluded to attempts to do this
in the past at AT&T.  They were failures.  It is not enough to decree a
standard; one must also convince people to accept it.  The getopt standard
has been widely accepted precisely *because* it tidies up and standardizes
the existing situation, rather than trying to impose radical change.

There are also problems with full-word options, and worse problems with
full-word options that can be arbitrarily abbreviated, but I won't get
into that since it seems a digression.

I've thought about this at considerable length, and concluded that radical
change will require more incentive than a simplistic revision of command
syntax would provide.  VMS-style "completion" isn't enough.  What one wants
is much more sophisticated help in command construction, including things
like interactive "help" information for options, knowledge of the semantics
of arguments so that error repair can be applied, etc.  Imbedding this into
every program seems dubious; it would seem better to have a sophisticated
shell which uses a database describing the commands.  Note that such an
interface could completely hide the details of the *actual* command syntax.
Someday...
                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,linus,decvax}!utzoo!henry

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

Volume-Number: Volume 1, Number 33

From jsq  Sun Jul 21 13:05:04 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 21 Jul 85 18:04:51 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 36
Approved: [e-mail]
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:     ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
Uucp-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
Draft-9: 2.5 3.2

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: standardizing exit codes
    It's not quite the same as standardized error messages,
    but close enough to keep in the same discussion.

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

Date: Sat, 20 Jul 85 16:52:04 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!std-unix
Subject: Standardizing exit codes

There is currently no universal standard for the meaning of exit codes,
except that 0 means "true" or "success" and non-zero means "false" or
"failure".  Some System V programs use 2 for syntax errors, failure to open
files, and the like, and 1 for "the command was run properly but gives a
result of 'false'".  "delivermail" and "sendmail" expect programs they run
to exit with an error code from the include file <sysexits.h> which has a
number of exit codes which further break down "failure to execute properly"
(like exit code 2 in those System V commands) into "incorrect usage", "input
data incorrect", "input file could not be opened", etc..

It might be useful to adopt some convention like that of <sysexits.h>.  Exit
code 0 would mean "the command executed without problems and returns a
'true' result; exit codes from 1 to some number N1 - 1 would mean "the
command executed without problems and returns a 'false' result" - the exit
code could be used to further specify the type of "false" result, if
desired; exit codes from N1 to 254 could mean "the command did not execute
successfully" and the exit codes from <sysexits.h> could break this down
further; and exit code 255 would be reserved for forked-off child processes
which were supposed to "exec" something but the "exec" failed.  (In
<sysexits.h>, N1 has the value 64.)

    Guy Harris

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

Volume-Number: Volume 1, Number 34

From jsq  Sun Jul 21 13:06:56 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Non-blocking I/O and EWOULDBLOCK vs. EAGAIN
Message-Id: <[e-mail]>
Date: 21 Jul 85 18:06:36 GMT
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 31
Approved: [e-mail]
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:     ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
Uucp-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
Draft-9: 5.4 6.0

Date: Sat, 20 Jul 85 16:41:57 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!std-unix
Subject: Non-blocking I/O and EWOULDBLOCK vs. EAGAIN

The /usr/group standards committee has essentially adopted 4.2BSD-style
non-blocking I/O, rather than System V-style non-blocking I/O.  The System V
Interface Definition says that System V will be changed to match the
/usr/group standard.

However,

    1) as the S5ID states, this may break existing code as it isn't
       compatible with existing System V implementations.

and

    2) it's not compatible with 4.2BSD, either, because they return
       EAGAIN if a non-blocking operation would have blocked had the
       descriptor been in non-blocking mode, rather than EWOULDBLOCK.

Is there a good reason for constructing a new specification, incompatible
with *all* existing systems, rather than adopting the existing 4.2BSD
facility which provides the same functionality and merely uses a different
error code?  "The committee didn't want to add a new error code" is an
extremely bad reason, as they have already added new error codes for the
benefit of file locking.  UNIX error codes are far too overloaded already;
the problem should not be compounded.

    Guy Harris


Volume-Number: Volume 1, Number 35

From jsq  Tue Jul 23 10:50:07 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Retransmissions and dead subjects.
Message-Id: <[e-mail]>
Date: 23 Jul 85 15:49:55 GMT
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 28
Approved: [e-mail]
Draft-9: mod.std.unix

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: Retransmissions and dead subjects.
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

The next four articles I will post to this newsgroup are retransmissions.
This is because, in an overly clever attempt to reduce the overhead of
the information formerly at the end of each article, I added the five
non-standard headers you now see included as part of the text above.
This is perfectly proper according to both the news article and mail
message format specifications.  However, some news (or notes) version
out there cannot handle either non-standard headers or sheer numbers
of headers and truncated all the articles which contained them.  Also,
as Robert Elz points out, most news reading programs will not display
the extra headers anyway unless the user explicitly asks for them.

Several people have complained that the getopt discussion is getting
overly verbose for the amount of information conveyed.  In particular,
implementation details of the standard I/O library are rather peripheral
to the standards effort, and would fit more readily in net.unix-wizards
or mod.unix than in mod.std.unix.  If you submit an article on getopt,
try to make it something new.  Better:  let's go on to other topics.

I am, however, still hoping someone will determine if there really is
a public domain AT&T getopt and submit it, if so.

Volume-Number: Volume 1, Number 36

From jsq  Tue Jul 23 12:40:08 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt (retransmitted)
Message-Id: <[e-mail]>
Date: 23 Jul 85 17:40:03 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 44
Approved: [e-mail]
Draft-9: 1003.2.getopt

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

From: seismo!BBN-LABS-B.ARPA!dan (Dan Franklin)
To: ut-sally!BBN-LABS-B.ARPA!std-unix
Subject: Re: a bit more on getopt
Date: 19 Jul 85 11:32:03 EDT (Fri)

>  > Actually this is important in some applications which do not already use
>  > stdio and do not wish to load in the 10k or so overhead that using stdio
>  > incurs. AT&T's code does not use stdio in getopt(3).
>
>  Not true.  The size difference between:
>
>      main() { puts("foo"); }
>  and
>      main() { write(0,"foo",3); }
>
>  is exactly zero.

Your second one-liner is still using stdio.  The difference between
       main() { puts("foo"); }
and
       main() { write(1, "foo", 3); }   exit(n) { _exit(n); }
on the other hand, is substantial, at least on my 4.2 VAX system (and, in my
experience, on other UNIX systems as well):

text    data    bss    dec    hex
2048    1024    15988    19060    4a74    stdio
1024    1024    0     2048     800    nostdio

1024       0    25988   17012           difference

The point about not using stdio in a library routine if it's not necessary
still stands.

    Dan Franklin

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 37

From jsq  Tue Jul 23 12:41:51 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: a bit more on getopt (retransmitted)
Message-Id: <[e-mail]>
Date: 23 Jul 85 17:41:46 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 220
Approved: [e-mail]
Draft-9: 1003.2.getopt

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: command line arguments (getopt) (retransmission of earlier article)
    Is the AT&T getopt public domain, or just published?
    AT&T getopt(3) man page is inaccurate.
    Inclusion of stdio and size of programs.
    Options, white space, and shell scripts.
    Full word command names and arguments, and completion.

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 19 Jul 85 20:14:44 CDT (Fri)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Is AT&T getopt public-domain?  Not clear!

The document I have from the /usr/group standards meeting at Dallas
does *not* say that the AT&T getopt is being made public domain.  What
it says is:

    The [getopt] source code is being published by AT&T Bell
    Laboratories to encourage adherence to the command syntax
    standard and to satisfy requests from [everyone in sight].

Note that publishing something does *not* put it into the public domain
unless this is stated explicitly.  That may have been AT&T's intent, but
they didn't say it that way.  The document in question includes the AT&T
source, but I am reluctant to submit it to mod.std.unix until its status
is clarified.

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

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

Date: 20 Jul 85 11:03:28 EDT (Sat)
From: topaz!packard!nomad!ggr (Guy Riddle)
Subject: getopt: the Code vs. the Manual Page
To: ut-sally!std-unix
Cc: seismo!keith

I hope you haven't been modelling the 4.3 version of getopt(3) too
closely after the SVR2 manual page, for it lies about the details.

It states

    "Because optind is external, it is normally initialized to
    zero automatically before the first call to getopt."

Well, I'll grant that optind is external, but it is initialized to one.

Also, the claim that

    "This error message may be disabled by setting opterr
    to a non-zero value."

is also a lie.  Opterr is initialized to one, and to disable the error
message you must set it to zero.

        === Guy Riddle == AT&T Bell Laboratories, New Jersey ===

----------
|Rebuttal
|Corner
|
    Keith's assertion that

    > Not true.  The size difference between:
    >
    >     main() { puts("foo"); }
    > and
    >     main() { write(0,"foo",3); }
    >
    > is exactly zero.

    might be valid for 4.2, but it's not for SVR2, where the size of the
    puts(3) version is

        2432 + 456 + 2232 = 5120

    while the write(2) version is only

        128 + 12 + 0 = 140

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

From: ihnp4!decvax!borman (Dave Borman)
Date: Sat, 20 Jul 85 21:01:42 edt
To: decvax!ihnp4!ut-sally!std-unix
Subject: getopt(3) & stdio

>  >  > Actually this is important in some applications which do not already use
>  >  > stdio and do not wish to load in the 10k or so overhead that using stdio
>  >  > incurs. AT&T's code does not use stdio in getopt(3).
>  >
>  >  Not true.  The size difference between:
>  >
>  >      main() { puts("foo"); }
>  >  and
>  >      main() { write(0,"foo",3); }
>  >
>  >  is exactly zero.
>
>  Your second one-liner is still using stdio.  The difference between
>     main() { puts("foo"); }
>  and
>     main() { write(1, "foo", 3); }   exit(n) { _exit(n); }
>  on the other hand, is substantial, at least on my 4.2 VAX system (and, in my
>  experience, on other UNIX systems as well):

The first two examples are different, the puts() will pull in stdio and
the write() should not.  If you have to explicitly re-declare exit() to
avoid pulling in the stdio package, then your /lib/libc.a is mucked up.
exit() calls _cleanup, of which there are two copies in the /lib/libc.a.
The stdio package has a function _cleanup which flushes all the buffers.
There is also a dummy _cleanup routine (usually fakcu.s) which just
returns.  In /lib/libc.a, exit() must be archived after all the stdio
functions, and the dummy _cleanup must be archived after exit.  If you
have exit() before the stdio functions, then the reference to _cleanup
will pull in the whole stdio package.  If exit() is after the stdio
package and the dummy _cleanup after exit(), then if you don't reference
any stdio functions you will only pull in the dummy cleanup routine.

        -Dave Borman, Digital UNIX Engineering Group.
        decvax!borman

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

Date: Sat, 20 Jul 85 16:31:33 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!jsq
Subject: Re: a bit more on getopt

> Not true.  The size difference between:
>
>    main() { puts("foo"); }
> and
>    main() { write(0,"foo",3); }
>
> is exactly zero.

Only true on certain UNIX implementations.  Under Sun UNIX 2.0
(4.2BSD-based), there is a slight difference.  Under System V there is a
significant difference.  The problem is that 4.2BSD *always* drags in the
Standard I/O Library while System V doesn't.  4.xBSD could be changed, with
about 30 minutes work, to work the way System V does here, so the assumption
should be made that the Standard I/O Library does consume a nonzero amount
of code and data space.  (About 13788 bytes in one test I did; this doesn't
count buffers which are "malloc"ed when the first read/write is done.)

    Guy Harris

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 20 Jul 85 20:45:50 CDT (Sat)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Re: a bit more on getopt
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>

> > ...  The "-t/dev/tty" example is an easy one
> > to pick out, but what about "-dfaglop"?  Which of those letters are
> > options, and which are an option argument?
>
> OK, instead of forcing whitespace, how about requiring that there only be one
> flag if you are going to do this sort of stuff? I have had shell scripts
> totally broken by this requirement, and workarounds take up so much overhead
> (yes, some people have systems smaller than vaxen) that it's not worth the
> hassle.

We do a *lot* of shell programming, and our experience is that the
separating blank makes life easier, not harder.  Of course, we generally
use getopt(1) for the argument parsing, which makes life simpler.  utzoo
is a PDP11, by the way.

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

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 19 Jul 85 20:15:23 CDT (Fri)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Command lines

> It's probably way too late for this to be suggested, but the longer it's
> left, the worse it will be.
> How about completely revamping the unix command line syntax to be
>     command {{-option ...} {file ...} ...}
> with command names & option names being full words (e.g. remove, not rm)...

The AT&T command-line-syntax people have alluded to attempts to do this
in the past at AT&T.  They were failures.  It is not enough to decree a
standard; one must also convince people to accept it.  The getopt standard
has been widely accepted precisely *because* it tidies up and standardizes
the existing situation, rather than trying to impose radical change.

There are also problems with full-word options, and worse problems with
full-word options that can be arbitrarily abbreviated, but I won't get
into that since it seems a digression.

I've thought about this at considerable length, and concluded that radical
change will require more incentive than a simplistic revision of command
syntax would provide.  VMS-style "completion" isn't enough.  What one wants
is much more sophisticated help in command construction, including things
like interactive "help" information for options, knowledge of the semantics
of arguments so that error repair can be applied, etc.  Imbedding this into
every program seems dubious; it would seem better to have a sophisticated
shell which uses a database describing the commands.  Note that such an
interface could completely hide the details of the *actual* command syntax.
Someday...
                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,linus,decvax}!utzoo!henry

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 38

From jsq  Tue Jul 23 12:43:39 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages (retransmitted)
Message-Id: <[e-mail]>
Date: 23 Jul 85 17:43:34 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 42
Approved: [e-mail]
Draft-9: 2.5 3.2

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: standardizing exit codes
    It's not quite the same as standardized error messages,
    but close enough to keep in the same discussion.

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

Date: Sat, 20 Jul 85 16:52:04 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!std-unix
Subject: Standardizing exit codes

There is currently no universal standard for the meaning of exit codes,
except that 0 means "true" or "success" and non-zero means "false" or
"failure".  Some System V programs use 2 for syntax errors, failure to open
files, and the like, and 1 for "the command was run properly but gives a
result of 'false'".  "delivermail" and "sendmail" expect programs they run
to exit with an error code from the include file <sysexits.h> which has a
number of exit codes which further break down "failure to execute properly"
(like exit code 2 in those System V commands) into "incorrect usage", "input
data incorrect", "input file could not be opened", etc..

It might be useful to adopt some convention like that of <sysexits.h>.  Exit
code 0 would mean "the command executed without problems and returns a
'true' result; exit codes from 1 to some number N1 - 1 would mean "the
command executed without problems and returns a 'false' result" - the exit
code could be used to further specify the type of "false" result, if
desired; exit codes from N1 to 254 could mean "the command did not execute
successfully" and the exit codes from <sysexits.h> could break this down
further; and exit code 255 would be reserved for forked-off child processes
which were supposed to "exec" something but the "exec" failed.  (In
<sysexits.h>, N1 has the value 64.)

    Guy Harris

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 39

From jsq  Tue Jul 23 12:46:24 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Non-blocking I/O and EWOULDBLOCK vs. EAGAIN (retransmitted)
Message-Id: <[e-mail]>
Date: 23 Jul 85 17:46:19 GMT
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 40
Approved: [e-mail]
Draft-9: 5.4 6.0

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

Date: Sat, 20 Jul 85 16:41:57 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!std-unix
Subject: Non-blocking I/O and EWOULDBLOCK vs. EAGAIN

The /usr/group standards committee has essentially adopted 4.2BSD-style
non-blocking I/O, rather than System V-style non-blocking I/O.  The System V
Interface Definition says that System V will be changed to match the
/usr/group standard.

However,

    1) as the S5ID states, this may break existing code as it isn't
       compatible with existing System V implementations.

and

    2) it's not compatible with 4.2BSD, either, because they return
       EAGAIN if a non-blocking operation would have blocked had the
       descriptor been in non-blocking mode, rather than EWOULDBLOCK.

Is there a good reason for constructing a new specification, incompatible
with *all* existing systems, rather than adopting the existing 4.2BSD
facility which provides the same functionality and merely uses a different
error code?  "The committee didn't want to add a new error code" is an
extremely bad reason, as they have already added new error codes for the
benefit of file locking.  UNIX error codes are far too overloaded already;
the problem should not be compounded.

    Guy Harris

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 40

From jsq  Wed Jul 24 11:16:17 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 24 Jul 85 16:15:55 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 36
Approved: [e-mail]
Draft-9: 2.5

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: Re: standardized error messages

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

From: oliveb![e-mail] (Jerry Aguirre)
Date: Mon, 22 Jul 85 21:42:10 pdt
Subject: Re: standardized error messages
References: <[e-mail]>

> From: Mike Trachtman  <[e-mail]>
> Is any thought being given to having the compilers, grep, etc.
> give error messages in a standard form, so
> that programs will be able to parse them.

The sys V announcment that I attended included discussion not only of
getopt but of an error library routine.

I don't have the syntax handy but it included the severity of the error
(warning vs. error vs. fatal), a user supplied message, and optionally
the errno determined system error message.

I have seen several postings of source which use a similar routine.
Does anyone at ATT care to comment on whether an error routine will be
included and what the syntax is?

                Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 41

From jsq  Thu Jul 25 09:55:37 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 25 Jul 85 14:55:26 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 47
Approved: [e-mail]
Draft-9: 2.5

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: Re: standardized error messages

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

Date: Sun, 21 Jul 85 05:19:11 pdt
From: seismo!nsc!daisy!david (David Schachter)
To: ut-sally!jsq
Subject: Re: standardized error messages
In-Reply-To: <[e-mail]>

Daisy's version of the UNIX(tm) operating system has a standard
way of handling error reporting.  You call a system routine,
passing it an error file number and an error status.  You also
pass a flag saying how to handle the error and substitution var-
iables.  The system looks up the error file number in a table to
get the names of the error file.  It then looks up in the file the
appropriate error message, using a simple transformation of the
error status as the key.  The strings in the error file are sim-
ilar in format to the 'printf' function thus allowing you to
substitute variables into the error message.

The flag you pass tells the system whether to display the message,
add it to the stack, display the entire stack (clearing it), or
jump to the machine monitor with a fatal error.  Obviously, the
latter case is used only when the error is on the order of "system
corrupt."

You can also pass an error port id if you do not wish the message
to go to std_err.

A subtle advantage of this is that all error messages reside in
external text files, not compiled into the code of the programs.
This results in faster loading, less memory usage, and makes it
easy to change error messages and to enforce consistent style.

[This does not represent official policy by Daisy Systems.  The
author speaks only for himself.] {"Where there's a will, there's
a won't."}

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 42

From jsq  Fri Jul 26 12:48:51 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Command completion in csh/sh
Message-Id: <[e-mail]>
Date: 26 Jul 85 17:48:39 GMT
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 35
Approved: [e-mail]
Draft-9: 1003.2.getopt

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

Date: Thu, 25 Jul 85 08:28:34 pdt
From: ihnp4!celerity!barto
To: bang!ihnp4!ut-sally!std-unix
Subject: Command completion in csh/sh

I have taken the twenex command completion code from the csh as
posted quite some time ago, and integrated it into the bourne shell
as distributed for V.2 from BRL.

Thus command completion now exists for the bourne shell.  These mods
will be made available to the general public through gatech!arnold.
(PLEASE DONT BOTHER HIM ABOUT THEM NOW.  THEY WILL BE POSTED WHEN HE
IS READY TO! And don't bug me about them, as I will only tell you to
wait until the posting from Arnold is ready.)

This is just to let all of you out there know that we have not forgotten
the 'standard shell' users.

--
David Barto, Celerity Computing, San Diego Ca, [phone]
decvax-\    bang-\            ARPA: celerity![e-mail]
ucbvax--\   akgua-\
ihnp4----\-sdcsvax-\-celerity!barto

    "There are no moral lessons in nature" - Darwin

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 43

From jsq  Thu Aug  1 15:43:56 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 1 Aug 85 20:43:46 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 134
Approved: [e-mail]
Summary: if this doesn't get standardized, everybody will do it anyway
Draft-9: 2.5

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: standardized error messages

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

From: oakhill!mot!fred (Fred Christiansen)
Date: Fri, 26 Jul 85 16:19:00 cdt
To: oakhill!ut-sally![e-mail]
Subject: Re: standardized error messages

the SVID has specifics in Appendix BASE 5.6 (p. 341), which i shall attempt
to summarize:
    the std error msg has 5 parts:
        Label        who's issuing this msg
        Severity    4 possible codes (halt, error, warning, fyi)
        Problem        what went wrong
        Action        "TO FIX" do such and such
        Tag        unique error msg id which can be used to
                track down more info

Fred Christiansen ("Canajun, eh?") @ Motorola Microsystems, Tempe, AZ
UUCP:  ihnp4!{attunix, btlunix, drivax, sftig, ut-sally!oakhill}!mot!fred
ARPA:  oakhill!mot![e-mail]             AT&T:  602-438-3472

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

From: Mike Trachtman  <[e-mail]>
Date: Sun, 28 Jul 85 14:59:04 -0200
To: [e-mail]
Subject: standard error messages.

A standard for error messages should be very strict about punctuation,
and where line numbers go.
somthing like

command: filename (linenumber) - severity - message

this is getting kind of IBMsh, but programs should be able
to parse errors, and thus errors should be in a standard form.

errors should definitely include the following

1) the filename where the error was
2) the line number
3) the error, (or in greps case, the line that contained the word

optionally, but in a set format

1) the command or routine that found the error
2) the Unix errno
3) some program generated error number
4) an indication of the severity

Of course, these are only opinions, and they are only my opinions.
Mike

        wizard@wisdom                           (BITNET)
        [e-mail]        (ARPA/CSNET)
        wizard%wisdom.bitnet@berkley            (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
        ...!decvax!humus!wisdom!wizard          (UUCP)

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

Date: Wed, 24 Jul 85 16:18:22 edt
From: Chris Torek <chris@maryland>
To: std-unix@ut-sally
Subject: Re: standardized error messages

Hm.  It's probably too late, but I would suggest that any standard
library routine for printing error message use printf-style
conversions (preferably it should be exactly like printf once you
get past severity stuff and whatnot).

In case anyone wants it, here's the routine I installed in our C
library on our "experimental" machine (it wants a bit of support
in the startup code to set _argv0 to argv[0], so that the program
name is included in error messages, but will work without it).  It
is not (alas!) portable, but can be made to work on any of the
popular Unix machines.  (I have a manual entry, if anyone cares.)

Chris

#include <stdio.h>

char *_argv0;            /* argv[0], set by C startup code */

/*
 * error - University of Maryland specific (sigh)
 *
 * Useful for printing error messages.  Will print the program name
 * and (optionally) the system error associated with the values in
 * <errno.h>.
 *
 * Note that the type (and even the existence!) of ``arg'' is undefined.
 */
error(quit, e, fmt, arg)
    int quit;
    register int e;
    char *fmt;
{
    extern char *sys_errlist[];
    extern int sys_nerr;
    register char *p = _argv0;

    if (p != NULL) {
#ifdef optional
        char *s, *rindex();

        if ((s = rindex(p, '/')) != NULL)
            p = s + 1;
#endif
        (void) fprintf(stderr, "%s: ", p);
    }
    _doprnt(fmt, &arg, stderr);    /* magic */
    if (e > 0) {
        p = e < sys_nerr ? sys_errlist[e] : "unknown error";
        (void) fprintf(stderr, ": %s", p);
    }
    (void) putc('\n', stderr);
    (void) fflush(stderr);
    if (quit)
        exit(quit);
}

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)



Volume-Number: Volume 1, Number 44

From jsq  Thu Aug  1 15:46:11 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Storage allocators
Message-Id: <[e-mail]>
Date: 1 Aug 85 20:46:03 GMT
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 30
Keywords: stack allocation, standardizing undocumented features
Approved: [e-mail]
Draft-9: 8.1

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

Date: Wed, 31 Jul 85 13:14:10 edt
From: Arnold Robbins <gatech!arnold>
Subject: Storage allocators
To: cbosgd!std-c, ut-sally!std-unix
Keywords: stack allocation, standardizing undocumented features

Unix has long had an undocumented routine alloca(), which allocates
storage off the stack.  This storage then goes away when the function
returns.

I would like to see this documented in the Unix standard under development,
and also included in the new ANSI C standard.  I would suggest that
the name get changed to something like salloc() [stack alloc], with
semantics similar to malloc (returned storage probably initialized to
garbage), only the storage is temporary, not permanent.

I think that cross posting to both groups is appropriate, since C supports
variables on the stack, so I doubt that there are many machines which can't
do alloca(), and for Unix, it comes down to documenting something that
has been there for a long time.

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 45

From jsq  Sun Aug  4 13:16:49 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-Id: <[e-mail]>
Date: 4 Aug 85 18:16:43 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 21
Keywords: stack allocation, standardizing undocumented features
Approved: [e-mail]
Draft-9: 8.1

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

Date:     Fri, 2 Aug 85 17:37:19 EDT
From: Doug Gwyn <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject:  Re: alloca()

No!  It is not always possible to implement alloca().  Neither Gould
nor I could make it work on UTX-32.  We very definitely do not need
this sort of critter in any standards!

(It also adds no functionality and encourages sloppy coding practice.)

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 46

From jsq  Sun Aug  4 13:21:11 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 4 Aug 85 18:21:06 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 27
Approved: [e-mail]
Draft-9: 1003.2.getopt 2.5

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

Date: Wed, 31 Jul 85 00:34:17 mdt
From: seismo!cmcl2!lanl!unmvax!unmc!galway (Denis McKeon)
To: ut-sally!std-unix
Subject: Re: getopt standard reference

I don't have machine readable version of Hemenway & Armitage
presentation, but their article in UNIX/World Vol. 1 No. 3
covers the choices, tradeoffs, & arguments well, and should be widely
available in the community. Perhaps U/w could post the copy?

dm


Denis McKeon, P.O. Box 4925, Albuquerque, NM 87196

    ~{convex,ucbvax,gatech,csu-cs,anl-mcs}!unmvax!unmc!galway
    ~{pur-ee!purdue,ucbvax!lbl-csam,philabs!cmcl2}!lanl!unmc!galway

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 47

From jsq  Mon Aug  5 10:12:34 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-Id: <[e-mail]>
Date: 5 Aug 85 15:12:28 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 22
Approved: [e-mail]
Draft-9: 8.1

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

Date: Mon, 5 Aug 85 10:04:43 edt
From: Arnold Robbins <gatech!arnold>
To: [e-mail]
Subject: Re: alloca()
Cc: cbosgd!std-c, ut-sally!std-unix

Well, I just sort of liked the idea of using storage on the stack. It
is really nice for dynamic arrays.  I'll agree that it can lead to poor
coding practices.  The Gould must have a very interesting architecture
if alloca wouldn't work on it.

Arnold

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 48

From jsq  Mon Aug  5 12:46:45 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-Id: <[e-mail]>
Date: 5 Aug 85 17:46:28 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 45
Approved: [e-mail]
Draft-9: 8.1

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

From: seismo!BBN-LABS-B.ARPA!dan
To: ut-sally!BBN-LABS-B.ARPA!std-unix
Subject: Re: Storage allocators
Date: 05 Aug 85 12:30:18 EDT (Mon)

Much as I like alloca() in theory, I have to agree with Doug Gwyn that it is
not always implementable--at least, if you are starting with the runtime
environment already designed.  Alloca() is a LANGUAGE feature, not a library
feature; it just happens that on many UNIX machines it is possible to add it to
the library and slip it past the compiler as long as you don't try to use it
too hard.  On many systems, if you do

    routine_with_args(arg1, arg2, arg3, ..., alloca(100), argN,...);

the alloca() will screw things up completely because the arguments before and
after it were pushed on the stack--that is, are SP-relative--and alloca() has
munged the SP.  Sufficiently complex expressions can also cause this problem.
Unless alloca() is known to the compiler it usually cannot be implemented
correctly.

However, I don't understand Doug's comment about it encouraging sloppy
programming practice.  Alloca() provides the programmer with the ability to
declare automatic variables whose size is determined at runtime rather than
compile time; thus the size can reflect the size of input data, which is GOOD
programming practice.  If the makers of UNIX had had alloca() when they did
execvp(), they would not have (a) relied on the existence of array[-1], or (b)
assumed that there would not be more than 200 values in the array (as different
versions of that library routine did).  I don't think anyone would argue that
the use of alloca here would have resulted in sloppier code!  The only
alternative, if you want to be a good programmer, is to use malloc(), which is
relatively slow and quite clumsy.  I have never subscribed to the point of view
that not having to explicitly allocate and free each variable is "sloppy
programming practice"; that's what auto vars are, after all.

    Dan Franklin

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 49

From jsq  Tue Aug  6 10:26:19 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 6 Aug 85 15:26:12 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 41
Approved: [e-mail]
Draft-9: 2.5

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

From: Steve Glaser <[e-mail]>
To: tektronix!ut-sally![e-mail],
        tektronix![e-mail]
Date: Mon, 5 Aug 85 17:58:33 PDT
Subject: Re: standardized error messages

in Chris Torek's error example, please change:

>    if (e > 0) {
>        p = e < sys_nerr ? sys_errlist[e] : "unknown error";
>        (void) fprintf(stderr, ": %s", p);
>    }

to:

>    if (e > 0) {
>        if (e < sys_nerr)
>            (void) fprintf(stderr, ": %s", sys_errlist[e]);
>        else
>            (void) fprintf(stderr, ": unknown error number %d", e);
>    }

It's most annoying when an error message printing routine throws away
information.  Especially when you have new error codes cropping up and
programs that don't get recompiled (or at least relinked).

At least Chris checked against sys_nerr.  I've seen may programs that
don't bother and end up printing gibberish when a new error comes along.

    Steve Glaser
    tektronix!steveg

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 50

From jsq  Tue Aug  6 17:41:15 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 6 Aug 85 22:41:02 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 104
Approved: [e-mail]
Summary: UNIX as TOPS-20
Draft-9: 2.5

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: standardized error messages

The idea proposed in this message has been proposed before in this newsgroup.
I am letting it through anyway, since this is a more complete description
of the idea.  After the flurry of rebuttals which will no doubt ensue,
I would prefer we not rehash it yet a third time.

If the discussion devolves into a TOPS-20 vs. UNIX flaming match, I will
at some point (soon) arbitrarily cut it off.

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

Date: Fri, 5 Jul 85 12:25:33 est
From: Stephen Uitti <seismo!pur-ee!pucc-h!ach>
Subject: Re: standardized error messages
To: ecn.ARPA!cbosgd!seismo!ut-sally!std-unix

>From: Douglas Spencer <seismo!mcvax!daisy!maugg>
>> some commands take arguments as
>> command -abcdefg filename
>> and some as
>> command -a -b -c -d -e -f -g filename
>> It would be great if this was standardised.
    The result being getopt, based on these rules:
>   - Command names must be between 2 and 9 characters ("kermit" is 6).
>   - Command names must include lower case letters and digits only.
>   - An option name is a single character.
>   - Options are delimited by '-'.
>   - Options with  no  arguments  may  be  grouped  (bundled)  behind  one
>     delimiter.
>   - Option-arguments cannot be optional.
>   - Arguments immediately follow options, separated by whitespace.
>   - The order of options does not matter.
>   - '-' preceded and followed by whitespace means standard input.
>A group of bundled options may end with an option that has an argument.
    I prefer to make a forward sighted change, rather than a backwords
compatibility of the problem.  Going from no standard to a bad one is
no gain.  At least with no standard, people had the option of doing it
"right".  Once a standard is invented, it can't really be changed:
the only recourse is to reinvent a new universe.  Rules I use for
new programs are:
1)     Command names must be real words or concatenations of words,
    max 9 characters (for V7 systems, for now).  They must not be
    one letter.  They should be more than 4.  Abreviations for
    parts of the command are acceptible, such as "mk" for "make" and
    "ck" for "check".  Especially if a real word can be used - "mkdepend".
    Suffixes are better - "filesysck" (might be a better name for "fsck").
    Siffixes allow the same abbreviation, but allow someone to write a
    command-completion or least-ambiguous command recognition shell.
2)     Command names should be lower case.
3)     Option names are real words.  Single letters are too difficult
    to remember.  They are to be parsed in a least ambiguous fashion.
4)     "-help" IS an option.  This gives a usage message and a one-line
    description of each option.  The manual page should be nearly
    superflous.  In interactive mode "?" gives a quick list of command
    names.
5)     Options start with a "-", on the command line.
6)     Options with arguments are of the form -foo=bar,foobar.
7)     Options do not get bundled together.  This is bogus.
8)     Option-argumets are optional.  The default is useful.
9)     If no options are given, something reasonable will happen.  If
    nothing reasonable can be done, a usage message will be printed.
10)    Having an interactive mode is not an unreasonable thing for a
    program to have.  The interactive mode HAS a prompt (which may
    be turned off/changed).
11)    Non-options are usually file names.
12)    Options and file names may be interspersed.  The order of options
    often matters.  If this is the case, left to right parsing is used.
    So, if two options (such as -optimize and -nooptimize) conflict,
    the rightmost will be used.  Note that "pascal -opt file2 -noopt
    file3" will optimize file2, but not file3.

    To this end, I have written a least ambiguous command parser
subroutine library which can be used from the command line and/or
interactively.  It works well.  I like to have billions of options
in my programs, but can never remember them.  Some of them are seldom
used.  Often, new options are added.  Shell scripts won't break if they
always used the whole option name.  Shell scripts are more readable if
they use the whole option name.  Usually one need only type one
or two letters of an option name.
    There are some programs out there that do least ambiguous command
parsing:  "lpc", "ftp" and "kermit" are some.  There's a whole operating
system too: "twenex".
    The reason I vote for such change is that UNIX is no longer V6,
with 50 commands, each with 5 options.  It's now 400 commands, each with
10 options.  V6 ran on an 11/40 that had a single RK05 (2.5 Megabytes),
full sources, with 300+ blocks left for the user (150 K bytes of disk).
RK05's are now little bigger than floppys (and little faster).  Now
if you only have 100 Meg devoted to /usr, you might not be able to have
quite everything on it.  News or sources might have to be put elsewhere.
Certainly your users will be elsewhere.
    The systems are bigger, and harder to maintain.  That's progress.
    Steve Uitti, PUCC, ...pur-ee!pucc-h!ach ([e-mail]).

(The opions expressed...)

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 51

From jsq  Tue Aug  6 17:45:21 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-Id: <[e-mail]>
Date: 6 Aug 85 22:45:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 37
Approved: [e-mail]
Draft-9: 8.1

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

Date: Tue, 6 Aug 85 01:11:53 PDT
From: seismo!sun!guy (Guy Harris)
To: cbosgd!std-c, ut-sally!std-unix
Subject: Re: Storage allocators

> Unix has long had an undocumented routine alloca(), which allocates
> storage off the stack.  This storage then goes away when the function
> returns.

*Some* UNIXes have had it.  It was a PWB/UNIX invention, and wiggled its way
into 4.xBSD; I don't remember it being in V7.

> ...since C supports variables on the stack, so I doubt that there are many
> machines which can't do alloca(), and for Unix, it comes down to
> documenting something that has been there for a long time.

If you said "I know that there are no machines which can't do 'alloca'", I'd
be more in favor of this proposal.  C supports variables on the stack, but
that merely requires that you can allocate a stack frame on procedure entry,
not that you can extend a stack frame during the execution of a procedure.
I would not be willing to say that all machines with C implementations can
do that.

>From the standpoint of UNIX, it's not clear that it's something that's been
there for a long time in *all* UNIXes.

    Guy Harris

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 52

From jsq  Sat Aug 10 17:16:43 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-Id: <[e-mail]>
Date: 10 Aug 85 22:16:36 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 96
Approved: [e-mail]
Draft-9: 8.1

From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: Storage allocaters (alloca)

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

From: ihnp4!hcr!hcrvx1!hugh
Date: 8 Aug 85 11:37:25 CDT (Thu)
To: hcr!ihnp4!ut-sally!std-unix
Subject: Re: Storage allocators

> ...since C supports variables on the stack, so I doubt that there are many
> machines which can't do alloca(), and for Unix, it comes down to
> documenting something that has been there for a long time.

alloca(), when implemented behind the back of a compiler is dangerous,
as described earlier ("f(..., alloca(...), ...)").  It also has a
potential performance penalty on EVERY function, not just those that use
it: with alloca, the system is forced to have a distinct frame pointer
and stack pointer.  Without the possibility of alloca, a frame pointer
is not needed (the activation record can be accessed by
known-at-compile-time offsets from the stack pointer).  Using two
registers instead of one could cause a noticeable increase in function
prologue/epilogue time.

I agree that the functionality of alloca() is useful, but it is not
sanely handled as a library routine.  ALGOL-60 got this right;
too bad its descendants didn't.

It appears that the C standard will give the compiler license to "know"
about library routines specified in the standard (and no others!).  Thus
the compiler would be able to treat alloca specially if it were included
in the standard.  Such a compiler might need an extra pass to be able to
avoid using a frame-pointer, and it would have to be able to generate
code both with and without a frame-pointer.  Even generating correct code
is tricky.  Perhaps, if alloca is standardized, it should be restricted
to certain usages, just as setjmp has been.

My hope is that alloca could be eliminated.  But even though it is
undocumented, there may be too many programs using it now.  Does anyone
know?

Perhaps this discussion should be in mod.std.c, not mod.std.unix.  I
hope that I have convinced you that this is a compiler/language issue,
not an isolated library issue.

[ The article that started the discussion was cross-posted to the two
newsgroups.  It's not clear that it still belongs in mod.std.unix,
but since it's involved UNIX history and implementation, I've seen
no reason to discourage it.  C library issues in general do more
properly belong in mod.std.c, though.  -mod ]

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

From: ihnp4!tektronix!hammer.TEK!steveh (Stephen Hemminger)
To: tektronix!ihnp4!seismo!ut-sally!jsq
Date: Fri, 9 Aug 85 09:14:33 PDT
Subject: Re: Storage allocators
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>

On the Tek NS32000 computers we have to fudge to get alloca() to work, but
I think the same technique might work on other computers.

The stack frame looks like:
    sp ->  ...
          saved registers (0 ... 8)
          local vars
    fp -> old fp
          args

The kludge we implemented for alloca was to allocate 32 bytes (8 regs)
more of storage and copy the top 32 bytes.  Unless the machine has
a huge number of registers, this technique should allow alloca on
any machine!

                |--|        |--|
  [I'd rather be skiing]    | /|        | /|
                .    |/ |        |/ |
                   .|--|        |--|
                | .|        |  |
    Stephen Hemminger    |  |.        |  |
    ([e-mail])        .
                   .
                 .
                    .

[ I've broken my rule of asking for explicit permission to post things
mailed to my personal address, since this one was an obvious submission. -mod ]

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 53

From jsq  Wed Aug 14 14:18:00 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: standardized error messages
Message-Id: <[e-mail]>
Date: 14 Aug 85 19:06:53 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 45
Approved: [e-mail]
Draft-9: 1003.2.getopt 2.5

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

Date: Sun, 11 Aug 85 23:20:34 edt
From: Ian! D. Allen <ihnp4!watmath!idallen>
To: ut-sally!std-unix
Subject: On interspersing options in command lines.

At Waterloo, we've used full-word options on our Honeywell/GCOS system
for years.  Gosh it makes reading the "man" pages easier!  We're bringing
an automated full-word-options parser to our UNIX systems now, and our
parser will have the "+help" self-documentation feature.  (At Waterloo
we use "+" and "-" for ON and OFF, rather than '-opt' and '-noopt'.)

Consider how the following syntax might be interpreted:

   $ commandname +optimize file1 -optimize file2 file3

1) Options are only recognized at the beginning of a command line.
   - file1 is optimized; file named '-optimize' is not found
2) Options are recognized where they are found, and apply to all
   following objects.
   - file1 is optimized; file2 and file3 are not optimized
3) Options apply to the entire command line, no matter where they are found.
   - option '+optimize' conflicts with '-optimize' and nothing is done

Waterloo is currently using the Type 3 interpretation.  If options
apply to the entire command line, no matter where they are typed, I can
enter the words on my command lines in the order I think of them.  I
find the most common way I enter command lines is to type in all the
file names first, then follow them with the modifying options I want.
In the rare (very rare) cases where I want to apply the same command
with different options to some files, I use separate command lines.

I claim that the convenience of letting users type in the words in the
order they want more than compensates for the resulting need to use
multiple commands every now and then.  (I'd love to have some survey data
to back this claim up.)

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 54

From jsq  Wed Aug 14 14:26:52 1985
Path: ut-sally!jsq
From: [e-mail] (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-Id: <[e-mail]>
Date: 14 Aug 85 19:15:38 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U. Texas CS Dept., Austin, Texas
Lines: 31
Approved: [e-mail]
Draft-9: 8.1

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

Date: Tue, 13 Aug 85 11:38:32 edt
From: seismo!allegra!phri!roy (Roy Smith)
To: ut-sally!std-unix
Subject: Storage allocation
Cc: roy

    I'm not sure if it is really germane to the issue at hand, but I
recently (yesterday) submitted to mod.sources a little package to handle
run time memory allocation for multi-dimensional arrays.  You might want to
take a look at it.

    Is it reasonable to include such a functionality in a Unix
standard?  I don't know if memory allocators should be considered part of
the C language, or part of the Unix OS, but given the fuss that went on
recently (in net.unix-wizards?) about the issue, it seems that it should be
addressed somewhere.  Of course, my implementation isn't necessarily the
best one (or even a good one), but I think the idea is sound.

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

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)

Volume-Number: Volume 1, Number 55