getopt(3) posting

BALDWIN mike at whuxl.UUCP
Thu Oct 24 08:37:10 AEST 1985


Not this again!

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

The most standard version I can think of is the one with System V.  IT CAN
PARSE "sort -mubdfnicrtx" JUST FINE.  And it certainly is not only AVAILABLE,
it is in the public domain.

> Not according to what I've seen. Getopt requires that flags with arguments
> stand alone.

You are confusing the "Proposed Syntax Standard for UNIX System Commands"
with getopt(3C).  Getopt only enforces SOME of those rules.  In particular,
it does NOT enforce Rule 6: "The first option-argument following an option
must be preceded by white space" or Rule 5: "Options with no arguments may
be grouped behind one delimiter."  That is, it allows options with arguments
to be grouped with other options.  The getopt man page doesn't say much at
all about whitespace, except for this: "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."  That's what you want, RIGHT?

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

This is not a problem.  Use the documented optind external variable:

	while (optind < argc)
		switch (getopt(argc, argv, "s:l:")) {
		case 's':
			speed = atoi(optarg);
			break;
		case 'l':
			strcpy(line, optarg);
			break;
		default:
			call(argv[optind++], speed, line);
			break;
		}

In fact, this is how getopt is used for System V cc.  Also, you said
something about getopt ignoring the order of arguments.  Again, you're
confusing the Proposed Syntax with getopt!  Getopt just returns you the
options in the order they were given and you can do whatever you want
with them!!

> I never said it did use stdio. All I said was that it's not of negligable
> size.

But it's not anything to worry about.  It doesn't use stdio, and it is
smaller than, e.g., atof, qsort, malloc, crypt, and ctime.

I really wish you would read things more carefully and not get all
worked up over situations that don't exist.  Nearly everything you've
said about getopt has been just plain WRONG.
-- 
						Michael Baldwin
						{at&t}!whuxl!mike



More information about the Comp.sources.bugs mailing list