getopt(3) posting

[Peter da Silva]

> In article <306 at graffiti.UUCP>, peter at 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.

Actually, I agree with you here. They're wrong. Most of them agree with you.

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

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.

> simply picked up the next character and continued on.  I think that "feature"
> can wander on out of our lives, don't you?

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.

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

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

> > 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:
> 
> ... code segment to demonstrate getopt doesn't care about argument order.
> 
> 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.

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?

> Besides, there's a very valid reason for
> programs ignoring argument order in general; it complicates the user interface
> unnecessarily.

But sometimes it's necessary. Like the above example. Or like any reasonable
permutation of "find".

> > nor for its inability to handle '+' and '-' type command flags...
> 
> 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.

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

> > And finally it's too big....
> 
> 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.

The above code parses any command list getopt can deal with and a whole bunch
more. It's not that complex.

> Getopt offers a clean, simple
			    incomplete
>				interface to command lines.  Secondly, your
> code is no more flexible than getopt.  The following code fragment will
> handle all of your examples.

Will it handle 'foo -g: file1 -g% file2 -sothg: file3'?

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

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

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

	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.

> Keith Bostic

Peter da Silva