Xref: utzoo comp.lang.c:9031 comp.unix.wizards:7653
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: command line options (UNIX-specific)
Message-ID: <1036@mcgill-vision.UUCP>
Date: 8 Apr 88 21:44:10 GMT
References: <2414@zyx.UUCP>
Organization: McGill University, Montreal
Lines: 56

In article <2414@zyx.UUCP>, aj@zyx.UUCP (Arndt Jonasson) writes:
> This is a suggestion for a command line parsing routine for C
> programs in Unix.

> I post this [suggestion] in the hope of getting constructive comments
> on what features are missing in my scheme, and whether it is perhaps
> too restrictive or too general [...].

Well, I can't say how constructive you will find these comments, but
here's a critique of what I dislike in what you've said.  (In the usual
tradition of criticism, I'll ignore the points you've mentioned that I
like. :-)

> 'O_parse_options' uses the same model as 'getopt', i.e. first come
> the options, preceded by hyphens (they may be grouped together after
> one hyphen), then come the non-option arguments.

How does one model an option which behaves like tar's -C or ld's -l,
which can appear (almost) anywhere and whose position is significant?

> If an option -s takes an argument, both '-sfoo' and '-s foo' are
> valid.

So you can group options on one hyphen - unless one of them takes an
argument.  Ugly inconsistency.  Also unpleasant: you can't use both
methods when the argument is to be a null string:

foo -s '' -b        - works
foo -s'' -b         - doesn't work

> It will either successfully parse all the options and store values in
> the appropriate variables, or exit the program with an error message.

I want the option of handling the error myself.  Perhaps I don't want
to print a usage message; perhaps I want a usage message that looks
different from yours; perhaps I want to produce the message on stdout
instead; perhaps I want to ignore the offending option; perhaps I want
to ignore the offending option depending on what it is....

How do you model the tar/dump/ar or dd styles of arglist?

I wrote a program a while back which took an option -F, which required
a following filename, as in

% foo -F xyzzy

except that the result was more verbose if the -F was doubled:

% foo -FF xyzzy

How would I model this?

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu