Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-june
Path: utzoo!linus!decvax!bellcore!petrus!sabre!zeta!epsilon!gamma!ulysses!
mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!uw-june!schwartz
From: schwartz@uw-june (Michael Schwartz)
Newsgroups: net.sources
Subject: getopt
Message-ID: <346@uw-june>
Date: Tue, 8-Oct-85 17:32:25 EDT
Article-I.D.: uw-june.346
Posted: Tue Oct 8 17:32:25 1985
Date-Received: Fri, 11-Oct-85 06:51:18 EDT
Organization: U of Washington Computer Science
Lines: 357
There has been a fair amount of software posted on the net which uses getopt,
but it took me a while to track down a copy of getopt for myself. Here it is,
including the manpage. The manpage output (as well as source) is included for
systems which can't process the manpage source.
--------------------------------- cut here ------------------------------------
############################################################
#
# getopt.ar
#
# To extract the files from this shell archive file
# simply create a directory for this file
# and move the archive file to it
# and enter the command
#
# sh filename.ar
#
# Do not use csh
# The files will be extracted automatically
#
############################################################
echo "Extracting getopt.3c <-- getopt.ar"
cat << \===getopt.3c=== > getopt.3c
.\" @(#)getopt.3c 1.1 83/08/30 SMI; from UCB 4.2
.TH GETOPT 3C "26 August 1983"
.SH NAME
getopt, optarg, optind \- get option letter from argv
.SH SYNOPSIS
.nf
.ft B
int getopt(argc, argv, optstring)
int args;
char **argv;
char *optstring;
.ft P
.LP
.ft B
extern char *optarg;
extern int optind;
.ft R
.fi
.SH DESCRIPTION
.ft B
This routine is included for compatibility with UNIX system-III.
It is of marginal value, and should not be used in new programs.
.ft R
.LP
.I Getopt
returns the next option letter in
.I argv
that matches a letter in
.I 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
.I getopt.
.LP
.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
.I getopt.
.LP
When all options have been processed (i.e., up to the first non-option
argument),
.I getopt
returns
.B \s-2EOF\s0.
The special option \-\- may be used to delimit the end
of the options;
.B \s-2EOF\s0
will be returned, and \-\- will be skipped.
.SH DIAGNOSTICS
.I Getopt
prints an error message on
.I stderr
and returns a question mark (?)
when it encounters an option letter not included in
.I 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
.B b,
and the options
.B f
and
.B o,
both of which require arguments:
.LP
.nf
.DT
main(argc, argv)
int argc;
char **argv;
{
int c;
extern int optind;
extern char *optarg;
\&\fB.\fP
\&\fB.\fP
\&\fB.\fP
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':
infile = optarg;
break;
case 'o':
ofile = optarg;
bufsiza = 512;
break;
case '?':
errflg++;
}
if (errflg) {
fprintf(stderr, "usage: . . . ");
exit(2);
}
for (; optind < argc; optind++) {
if (access(argv[optind], 4)) {
\&\fB.\fP
\&\fB.\fP
\&\fB.\fP
}
.fi
===getopt.3c===
# ----------
echo "Extracting getopt.c <-- getopt.ar"
cat << \===getopt.c=== > getopt.c
/*
* 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);
}
===getopt.c===
# ----------
echo "Extracting getopt.manpage <-- getopt.ar"
cat << \===getopt.manpage=== > getopt.manpage
GETOPT(3C) UNIX Programmer's Manual GETOPT(3C)
NAME
getopt, optarg, optind - get option letter from argv
SYNOPSIS
int getopt(argc, argv, optstring)
int args;
char **argv;
char *optstring;
extern char *optarg;
extern int optind;
DESCRIPTION
This routine is included for compatibility with UNIX
system-III. It is of marginal value, and should not be used
in new programs.
_G_e_t_o_p_t returns the next option letter in _a_r_g_v that matches a
letter in _o_p_t_s_t_r_i_n_g. _O_p_t_s_t_r_i_n_g 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. _O_p_t_a_r_g is set to point
to the start of the option argument on return from _g_e_t_o_p_t.
_G_e_t_o_p_t places in _o_p_t_i_n_d the _a_r_g_v index of the next
argument
to be processed. Because _o_p_t_i_n_d is external, it is normally
initialized to zero automatically before the first call to
_g_e_t_o_p_t.
When all options have been processed (i.e., up to the first
non-option argument), _g_e_t_o_p_t returns EOF. The special option
-- may be used to delimit the end of the options; EOF will
be returned, and -- will be skipped.
DIAGNOSTICS
_G_e_t_o_p_t prints an error message on _s_t_d_e_r_r and returns a ques-
tion mark (?) when it encounters an option letter not
included in _o_p_t_s_t_r_i_n_g.
EXAMPLE
The following code fragment shows how one might process the
arguments for a command that can take the mutually exclusive
options a and b, and the options f and o, both of which
require arguments:
main(argc, argv)
int argc;
char **argv;
{
int c;
extern int optind;
extern char *optarg;
Printed 10/8/85 26 August 1983 1
GETOPT(3C) UNIX Programmer's Manual GETOPT(3C)
.
.
.
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':
infile = optarg;
break;
case 'o':
ofile = optarg;
bufsiza = 512;
break;
case '?':
errflg++;
}
if (errflg) {
fprintf(stderr, "usage: . . . ");
exit(2);
}
for (; optind < argc; optind++) {
if (access(argv[optind], 4)) {
.
.
.
}
Printed 10/8/85 26 August 1983 2
===getopt.manpage===
# ----------
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcs.uucp
Path: utzoo!utcs!ian
From: i...@utcs.uucp (Ian F. Darwin)
Newsgroups: net.sources.bugs
Subject: getopt(3) posting FLAME
Message-ID: <910@utcs.uucp>
Date: Fri, 11-Oct-85 19:41:30 EDT
Article-I.D.: utcs.910
Posted: Fri Oct 11 19:41:30 1985
Date-Received: Sat, 12-Oct-85 00:46:44 EDT
Organization: University of Toronto - General Purpose UNIX
Lines: 26
Summary: getopt should be promoted, not abused.
To: schwartz@uw-june
In-Reply-To: <346@uw-june>
In article <346@uw-june> schwartz@uw-june includes (from
.\" @(#)getopt.3c 1.1 83/08/30 SMI; from UCB 4.2):
>This routine is included for compatibility with UNIX system-III.
>It is of marginal value, and should not be used in new programs.
I disagree. First, it is for compatability with USG UNIX (all
of them, not just System III (note spelling), but also System V,
System V Release 2, etc.).
Second, it is very useful and should be used in all new programs.
People should not write their own version of argument parsing
in every new program, and get it wrong, when a standard argument
parser is available.
Third, since did not write the code (the version you posted
was written at the University of Toronto), you should give credit
to the person who did. A difference of opinion is no excuse
for a lack of courtesy; taking somebody's name off code
that you don't like but haven't modified is certainly discourteous.
Sounds like something that might have happened to the code
in or around Berkeley; they are famous for trying to take
the credit for others' work by taking names off contributions.
Ian F. Darwin
Toronto, Canada
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 (Fortune 01.1b1); site graffiti.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!ut-sally!ut-ngp!
shell!graffiti!peter
From: pe...@graffiti.UUCP (Peter da Silva)
Newsgroups: net.sources.bugs
Subject: Re: getopt(3) posting FLAME
Message-ID: <306@graffiti.UUCP>
Date: Tue, 15-Oct-85 12:52:34 EDT
Article-I.D.: graffiti.306
Posted: Tue Oct 15 12:52:34 1985
Date-Received: Thu, 17-Oct-85 08:04:47 EDT
References: <910@utcs.uucp>
Organization: The Power Elite, Houston, TX
Lines: 68
Disclaimer: the following text should be ignored by 90% of the readers of
mod.std.c, since they've already gone through this.
> Second, it is very useful and should be used in all new programs.
> People should not write their own version of argument parsing
> in every new program, and get it wrong, when a standard argument
> parser is available.
Not when (as has been pointed out by many people) the standard argument parser
does the wrong thing. It can't even handle the arguments that sort(1) (V7)
uses, to wit:
sort -mubdfincrtx
Where the final 'tx' means 'tab character <x>'. The rest of sort's arguments
are even less parsable by getopt. There is no reason for getopt's
insistence on lots of whitespace, nor for its ignoring argument order, nor
for its inability to handle '+' and '-' type command flags...
And finally it's too big. If your program takes the following arguments:
foo [-someflags] [file]...
Which is the usual case, what's wrong with:
char *prog;
main(ac, av)
int ac;
char **av;
{
int flag = 0;
prog = *av;
while(av++, ac--)
if(**av=='-')
while(*++*av)
switch(**av) {
case 's': /* -s */
sflag++;
break;
...
case 'g': /* -g<s> */
if(av[0][1])
gchar = *++*av;
else if(av[1])
gchar = **++av;
else
usage(*av);
default:
usage(*av);
}
else {
FILE *fp = fopen(*av, "r");
if(fp) {
do_something_with(fp, *av);
fclose(fp);
}
flag = 1;
}
if(flag==0) /* no files processed */
do_something_with(stdin, "standard input");
}
which is not much more complex than the main you have to write with getopt to
do the same thing, allows more flexibility (foo -s -g:; foo -s -g :; foo -sg:;
foo -sg :), and produces a program that needs less core. If you think that's
a minor consideration, remember why vi doesn't use stdio on a PDP-11.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site seismo.CSS.GOV
Path: utzoo!watmath!clyde!cbosgd!seismo!keith
From: ke...@seismo.CSS.GOV (Keith Bostic)
Newsgroups: net.sources.bugs
Subject: Re: getopt(3) posting FLAME
Message-ID: <444@seismo.CSS.GOV>
Date: Wed, 16-Oct-85 19:31:26 EDT
Article-I.D.: seismo.444
Posted: Wed Oct 16 19:31:26 1985
Date-Received: Fri, 18-Oct-85 00:11:45 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP>
Organization: Center for Seismic Studies, Arlington, VA
Lines: 127
Summary: getopt(3) posting bucket of water
In article <3...@graffiti.UUCP>, pe...@graffiti.UUCP (Peter da Silva) writes:
> Disclaimer: the following text should be ignored by 90% of the readers of
> mod.std.c, since they've already gone through this.
Disclaimer: the following text should be read by 90% of the readers of
mod.std.c, 'cause they're purely wrong.
> Not when (as has been pointed out by many people) the standard argument parser
> does the wrong thing. It can't even handle the arguments that sort(1) (V7)
> uses, to wit:
>
> sort -mubdfincrtx
>
> Where the final 'tx' means 'tab character <x>'.
Wrong. What you're trying to do is assign the character 'x' to a char
variable, correct? Code can be written to use getopt that does this quite
nicely. Important code fragment:
case 't': /* tab char */
tabch = *optarg;
break;
> The rest of sort's arguments are even less parsable by getopt.
Wrong again. The *only* arguments that sort has that getopt can't handle
are the +/- flags. No, I take that back. The V7 sort also allowed you
"-mutxbd" where you could insert the argument into the flag string, and
the program realized the length of the argument as a single character and
simply picked up the next character and continued on. I think that "feature"
can wander on out of our lives, don't you?
> There is no reason for getopt's insistence on lots of whitespace,
Wrong. It doesn't insist on lots of whitespace, any more than any other
command interface. You can group flags together, e.g. "sort -efghi",
until you enter a flag that requires an argument. Then, you have to have
whitespace, otherwise there's no way to know when the argument terminates.
That's nothing new.
> nor for its ignoring argument order,
Wrong again. Why should getopt pay any attention whatsoever to argument
order? It's easy enough to implement if you really care about it:
short sflag = 0;
case 's': /* sflag */
++sflag;
break;
case 't': /* tflag */
if (sflag) {
puts("no.");
exit(-1);
}
but that has nothing to do with getopt. All getopt is supposed to do is
provide an interface to the user's command line. *Not* decide that the
flags are incorrectly ordered. Besides, there's a very valid reason for
programs ignoring argument order in general; it complicates the user interface
unnecessarily.
> nor for its inability to handle '+' and '-' type command flags...
Here, you may have a point. Getopt requires that all flags be preceded
by a '-', and that "--" denote the end of the arguments. Now, you can
certainly have "sort -+3.5"
while ((ch = getopt(argc,argv,"t+:")) != EOF)
switch((char)ch) {
case '+':
printf("got +: arg was <%s>\n",optarg);
break;
but not "sort --3.5". Now... how many programs really use '+' and '-'? And
just how much heartbreak is it going to cause you to enter "sort -mubd -s3.5
-e3.5" as opposed to the current "sort -mubd +3.5 -3.5"? There's a difference
of exactly two characters. I think this is a minor price to pay for a
consistent user interface.
> And finally it's too big. If your program takes the following arguments:
>
> foo [-someflags] [file]...
> Which is the usual case, what's wrong with:
... insert large example ...
> which is not much more complex than the main you have to write with getopt to
> do the same thing, allows more flexibility (foo -s -g:; foo -s -g :; foo -sg:;
> foo -sg :), and produces a program that needs less core. If you think that's
> a minor consideration, remember why vi doesn't use stdio on a PDP-11.
First off, the code to parse a command list sanely is fairly complex. Argv
is not an that easy a variable to handle, especially for novice programmers.
Getopt offers a clean, simple interface to command lines. Secondly, your
code is no more flexible than getopt. The following code fragment will
handle all of your examples.
while ((ch = getopt(argc,argv,"sg:")) != EOF)
switch((char)ch) {
case 's':
puts("got s");
break;
case 'g':
printf("got g: arg was <%s>\n",optarg);
break;
default:
puts("got nothing");
exit(ERR);
}
Secondly, the size differences are negligible. On a PDP or anywhere else.
Getopt doesn't use stdio, therefore your code isn't going to improve it
a lot.
Getopt is a good idea, folks.
-- it provides consistent syntax error messages
-- most programmers don't handle bizarre flag/argument combinations;
getopt takes care of that problem.
-- simplifies the effort of writing a command interface to the
copying of a while loop from your last program and editing
a couple of lines.
Keith Bostic
ke...@seismo.CSS.GOV
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site burl.UUCP
Path: utzoo!watmath!clyde!burl!rcj
From: r...@burl.UUCP (Curtis Jackson)
Newsgroups: net.sources.bugs
Subject: Re: getopt(3) posting FLAME
Message-ID: <898@burl.UUCP>
Date: Thu, 17-Oct-85 16:59:10 EDT
Article-I.D.: burl.898
Posted: Thu Oct 17 16:59:10 1985
Date-Received: Fri, 18-Oct-85 01:33:23 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP>
Reply-To: r...@burl.UUCP (Curtis Jackson)
Organization: AT&T Technologies, Burlington NC
Lines: 32
Keywords: Huh?!
Summary:
In article <3...@graffiti.UUCP> pe...@graffiti.UUCP (Peter da Silva) writes:
>[getopt] does the wrong thing. It can't even handle the arguments that
>sort(1) (V7) uses, to wit:
>
> sort -mubdfincrtx
>
>Where the final 'tx' means 'tab character <x>'. The rest of sort's arguments
>are even less parsable by getopt. There is no reason for getopt's
>insistence on lots of whitespace, nor for its ignoring argument order, nor
>for its inability to handle '+' and '-' type command flags...
All this is based in getopt from AT&T Unix Sys III and up:
Agreed that getopt cannot handle '+' type command flags, BUT -- it can indeed
handle the trailing tx mentioned above, it ignores whitespace between switches
that do not require arguments, and it does NOT ignore argument order. Sounds
to me like you have an inferior, 'non-standard' getopt.
>do the same thing, allows more flexibility (foo -s -g:; foo -s -g :; foo -sg:;
>foo -sg :), and produces a program that needs less core. If you think that's
>a minor consideration, remember why vi doesn't use stdio on a PDP-11.
Again, 'real' getopt will accept all of the above combinations of -s and -g
above. Agreed, it does add somewhat to the size of your program -- but since
I write microassemblers and compilers that generally have 15-20 command-line
switches I don't really mind -- it buys me a lot of clarity. Also, I am on
a Vax 11/780 with 10 meg main memory :-)
--
The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site elsie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!
elsie!ado
From: a...@elsie.UUCP (Arthur David Olson)
Newsgroups: net.unix
Subject: Re: getopt(3) posting FLAME
Message-ID: <5244@elsie.UUCP>
Date: Sat, 19-Oct-85 13:04:54 EDT
Article-I.D.: elsie.5244
Posted: Sat Oct 19 13:04:54 1985
Date-Received: Mon, 21-Oct-85 00:42:31 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP>
Organization: NIH-LEC, Bethesda, MD
Lines: 22
Keywords: Huh?!
Summary: What is reality?
> Again, 'real' getopt will accept all of the above combinations of -s and -g
> above. . .
I don't know about you, but I write code that gets used on machines other than
the one I use. I get to keep this in mind when I write the code. If I make
use of something that's available on my machine and that isn't available on
some other machine, I'll regret it down the line.
From this perspective, the "getopt" that's been posted to the network is the
"real" getopt. I know it'll be available on any machine my software goes to--
simply because I can put the posted version of getopt on the tape I send. The
AT&T version of getopt is "unreal" from this perspective--there's nothing I can
do (legally) to guarantee that it will be available at the receiving end. Of
course, there is something AT&T could do--put the source code for the "real"
getopt.c in the public domain. Hint, hint.
As always, the contents of this article are entirely my own responsibility.
--
UNIX is an AT&T Bell Laboratories trademark.
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!...@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!
harvard!seismo!brl-tgr!gwyn
From: g...@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix
Subject: Re: getopt(3) posting FLAME
Message-ID: <2271@brl-tgr.ARPA>
Date: Sat, 19-Oct-85 21:56:50 EDT
Article-I.D.: brl-tgr.2271
Posted: Sat Oct 19 21:56:50 1985
Date-Received: Mon, 21-Oct-85 00:46:06 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP> <5244@elsie.UUCP>
Organization: Ballistic Research Lab
Lines: 4
> ... Of course, there is something AT&T could do--put the source code
> for the "real" getopt.c in the public domain.
They already did that.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: a...@alice.UucP (Andrew Koenig)
Newsgroups: net.unix
Subject: Re: getopt(3) posting FLAME
Message-ID: <4463@alice.UUCP>
Date: Sun, 20-Oct-85 17:52:46 EDT
Article-I.D.: alice.4463
Posted: Sun Oct 20 17:52:46 1985
Date-Received: Mon, 21-Oct-85 01:04:40 EDT
References: <5244@elsie.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 11
> From this perspective, the "getopt" that's been posted to the network is the
> "real" getopt. I know it'll be available on any machine my software goes to--
> simply because I can put the posted version of getopt on the tape I send. The
> AT&T version of getopt is "unreal" from this perspective--there's nothing I can
> do (legally) to guarantee that it will be available at the receiving end. Of
> course, there is something AT&T could do--put the source code for the "real"
> getopt.c in the public domain. Hint, hint.
The source code for the "real" getopt.c is available at no charge
from the Unix (TM) System Toolchest. Dial (201) 522-6900 from your
1200 baud modem and log in as "guest" for further details.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site wcom.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!wcom!frodo
From: fr...@wcom.UUCP (Jim Scardelis)
Newsgroups: net.unix
Subject: Re: getopt(3) posting FLAME
Message-ID: <811@wcom.UUCP>
Date: Sun, 20-Oct-85 19:37:02 EDT
Article-I.D.: wcom.811
Posted: Sun Oct 20 19:37:02 1985
Date-Received: Mon, 21-Oct-85 07:38:44 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP> <5244@elsie.UUCP> The
Organization: Warner Computer Systems, Inc., Saddle Brook, NJ
Lines: 12
> AT&T version of getopt is "unreal" from this perspective--there's nothing I can
> do (legally) to guarantee that it will be available at the receiving end. Of
> course, there is something AT&T could do--put the source code for the "real"
> getopt.c in the public domain. Hint, hint.
The AT&T version of getopt(3c) is available for free, with free
sub-licensing from the AT&T Toolchest [(201) 522-6900, login: guest].
--
Jim Scardelis, SA
vax135!wcom!frodo
#include <favorite disclaimer>
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site maynard.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!
wjh12!maynard!campbell
From: campb...@maynard.UUCP (Larry Campbell)
Newsgroups: net.unix
Subject: Re: Re: getopt(3) posting FLAME
Message-ID: <173@maynard.UUCP>
Date: Mon, 21-Oct-85 00:41:51 EDT
Article-I.D.: maynard.173
Posted: Mon Oct 21 00:41:51 1985
Date-Received: Tue, 22-Oct-85 05:58:24 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP> <5244@elsie.UUCP>
<2271@brl-tgr.ARPA>
Organization: The Boston Software Works Inc., Maynard, MA
Lines: 16
> > ... Of course, there is something AT&T could do--put the source code
> > for the "real" getopt.c in the public domain.
>
> They already did that.
They did? Where can I get my copy?
--
Larry Campbell decvax!genrad
The Boston Software Works, Inc. \
120 Fulton St. seismo!harvard!wjh12!maynard!campbell
Boston MA 02109 / /
ihnp4 cbosgd
ARPA: campbell%maynard.u...@harvard.ARPA (broken because of bugs at Harvard)
or: maynard.UUCP:campb...@harvard.ARPA (works now but try above if no joy)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!
harvard!seismo!brl-tgr!gwyn
From: g...@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix
Subject: Re: Re: getopt(3) posting FLAME
Message-ID: <2311@brl-tgr.ARPA>
Date: Mon, 21-Oct-85 20:43:21 EDT
Article-I.D.: brl-tgr.2311
Posted: Mon Oct 21 20:43:21 1985
Date-Received: Wed, 23-Oct-85 05:03:04 EDT
References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP> <5244@elsie.UUCP>
<2271@brl-tgr.ARPA> <173@maynard.UUCP>
Organization: Ballistic Research Lab
Lines: 23
> > > ... Of course, there is something AT&T could do--put the source code
> > > for the "real" getopt.c in the public domain.
> >
> > They already did that.
>
> They did? Where can I get my copy?
In the paper "An Enhanced Getopt" by T.C. Jones & L.A. Kennedy
of AT&T Bell Labs, Summit NJ 07901. If you can't get it from
the authors, stay tuned; someone at Seismo may post the code.
"The enhanced getopt(1) and getopt(3c) source code is being
published by AT&T Bell Laboratories to encourage adherence to
the command syntax standard and to satisfy requests from both
the /usr/group Standards Committee and our customers. This
action is not a precedent since AT&T Bell Laboratories does
not plan on publishing any additional source code."
Incidentally, I strongly object to both the eventual enforcement
of rule 6 in getopt(3c), also enforced in the version that I
posted some time ago, and the change in behavior of getopt(1);
a DIFFERENT NAME such as getopts(1) should have been chosen, to
avoid breaking existing shell scripts that use the old getopt(1).
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site seismo.CSS.GOV
Path: utzoo!watmath!clyde!cbosgd!seismo!keith
From: ke...@seismo.CSS.GOV (Keith Bostic)
Newsgroups: net.sources.bugs
Subject: Re: getopt(3) posting
Message-ID: <498@seismo.CSS.GOV>
Date: Tue, 22-Oct-85 00:47:30 EDT
Article-I.D.: seismo.498
Posted: Tue Oct 22 00:47:30 1985
Date-Received: Wed, 23-Oct-85 05:07:02 EDT
Organization: Center for Seismic Studies, Arlington, VA
Lines: 98
Summary: more on getopt(3), wander on, it's boring.
References: <910@utcs.uucp> <306@graffiti.UUCP> <444@seismo.CSS.GOV>
<324@graffiti.UUCP>
> But according to the docs & both versions of getopt that have shown up on the
> net that won't do the same thing. According to them, you need:
>
> sort -mubdfincr -tx
> Now then: you may have an improved version of getopt, or the versions posted
> to the net may be incomplete or innacurate. In either case you still can't use
> *AVAILABLE* versions of getopt to parse those args.
There have been several versions of getopt(3) running around the public domain.
The one I'm talking about here I have posted to the net at least 3 times, once
to net.bugs, once to mod.sources, and once somewhere else. It is fully S5
compatible and handles the above case.
> Why? It's an unabiguous parse, and doesn't break anything to leave it in.
> I can see a situation where you have 2 flags like that: -tx -sx. Someone's
> going to type 'foo -s:t:' and get hit with an un-necessary error message.
This is a special case that just doesn't occur. You're stipulating that a
program takes two arguments of one character apiece, no more, no less. That's
the *only* way the above example becomes relevant. Since I can't think of a
single program with such an interface, I'm forced to conclude that its
sacrifice is a small price to pay for command line consistency.
> Not according to what I've seen. Getopt requires that flags with arguments
> stand alone.
No, it requires flags with arguments to be *followed* by whitespace. This is
standard in most command interfaces, since it can only be avoided by exact
knowledge of argument length.
> A counterexample to show you what I'm talking about:
>
> connect: a UNIX modem program that I wrote. It allows a series of
> phone numbers on the command line & keeps trying them until it gets one that
> works. Handy for calling bbs-es:
> usage: connect -s<baud> -l<line> number...
> Note: direct is considered a number for compatibility with cu.
>
> connect -s 1200 4445555 4446666 -s300 5556666 6667777 -l tty1 direct
>
> How would you deal with that using getopt, which seems to require that all
> options be before all arguments?
The key is your usage statement. Why doesn't ls allow "ls foo bar -l"? What's
wrong with expecting "connect -s<baud> -l<line> number..."? Answer: Nothing,
and it's easier. After all, that's what your usage statement says. Yes, we
could rewrite the UNIX application software universe so that programs parsed
their entire argv array *before* handling any of their arguments, but think how
much slower "ls /sys/sys/* -l" is going to be. Besides, the only real value
would accrue to programs that want to allow flags *per* argument, e.g. "nm -n
/vmunix -p /old_vmunix". And that too, has hidden problems; note in the
example I just gave, the flags 'p' and 'n' are contradictory -- how are you
going to handle that? Exactly what relationship are the flags going to have?
Do they apply to the entire command string, the command string after they
appear, or the command string until the next flag shows up? It's just not
worth the effort, especially since the problem can be solved without any
further effort by separating the commands, e.g. "nm -m /vmunix; nm -p
/old_vmunix". It should also be noted that the latter approach is much simpler
for Joe User to cope with.
> But sometimes it's necessary. Like the above example. Or like any reasonable
> permutation of "find".
No, not true. In either case. For connect it's no more necessary than it's
necessary for ls. And, on the basis of the 30 seconds of thought I've just
devoted to the problem, find doesn't need it either.
> The "tail" on the Tek development system I've been using has exactly that
> change, and it causes much heartbreak & swearing every time I forget and
> type "tail -60" instead of "tail -e 60".
A problem. For some reason UNIX decided early on that numbers didn't need
flags, while other arguments did, and people are used to that. Perhaps an
alias would be a nice solution here. I suspect that after a little practice
you'd become comfortable entering "tail -e60"; after all, you aren't suprised
when "mt /dev/rmt0 off" fails, are you? Why should tail be any different, just
because it's argument is numeric. It's the price you pay for not having to
list arguments in a specific order.
> I never said it did use stdio. All I said was that it's not of negligable
> size.
OK, I'll rephrase my answer. It's not significantly bigger than the code
you're going to have to write to parse the same arguments. And it's going
to be consistent, and it's going to be bug free, blah, blah, blah, ad nauseum.
> Well, the program I provided does all these things too, and allows you
> to handle multiple sets of options, variant option flags, and so on.
No, your program handled a special case. And I'll have to rewrite it each
time, twitching it just a little, to fit each new special case. I'm not
saying that you're never going to have to write such a beast. getopt just
makes those joyful occasions a rarity.
Keith Bostic
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!l5!gnu
From: g...@l5.uucp (John Gilmore)
Newsgroups: net.unix
Subject: Re: getopt(3) posting FLAME
Message-ID: <217@l5.uucp>
Date: Sat, 26-Oct-85 08:40:23 EST
Article-I.D.: l5.217
Posted: Sat Oct 26 08:40:23 1985
Date-Received: Mon, 28-Oct-85 03:49:11 EST
References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP> <5244@elsie.UUCP>
<811@wcom.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 27
In article <8...@wcom.UUCP>, fr...@wcom.UUCP (Jim Scardelis) writes:
> The AT&T version of getopt(3c) is available for free, with free
> sub-licensing from the AT&T Toolchest [(201) 522-6900, login: guest].
This is misleading. AT&T will sell it for free to anyone who is
signed up with the Toolchest, but you either have to pay $100 to sign
up, or own a source license ($43K). You also have to wait for them
to mail you a contract then you sign it and mail it back then they
eventually flip a bit that lets you "buy" things.*
Will someone who has already gone thru this please post the source
to the net.sources? The sublicense fee is $0 so you should be able to
"sell" it to all of us and AT&T doesn't care. Right?
(I've seen Henry Spencer's version and it seems to work just fine.
Is there any reason why I'd want the AT&T version?)
Flame about Toolchest: They seem to be afraid of Unix experts; they
stick you in a menu system and won't let you out. I wanted to see the
price ranges, but there's no way to get a simple list of tool names and
prices, unless you ask about each tool individually. Thanks AT&T.
* I think this is kind of funny, from the company that transacts
ALL its business over the phone. They never made me sign a contract
for phone service or long distance...I just call up, tell them I'm me
(or anybody else), and order what I want. It shows up on my phone bill.
Why can't they do that for the Toolbox?