Tech Insider					     Technology and Trends


			      USENET Archives

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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/