[getopt-sig] Comparing option libraries

A.T. Hofkamp a.t.hofkamp@tue.nl
Tue, 26 Feb 2002 17:20:51 +0100 (CET)


On Tue, 26 Feb 2002, Tony J Ibbs (Tibs) wrote:

> Hmm. Mattias Urlichs and (I think?) A.T. Hofkamp seem to think that
> "contradicting" oneself on the command line - for example::

Yes I do.

>     $ command -verify -noverify
>
> is a Bad Thing to do. In theory, I'm not sure that's wrong. However, in
> any situation where an "alias" has been defined for a command. this sort
> of thing can happen quite naturally. It's certainly been not uncommon on

I didn't realize this, but indeed, it may be the case.

> Whilst such use of an alias might be deemed bad style, it's difficult to
> see how it is entirely preventable, given it's a property of the OS or
> shell, not the command itself...

It is not (and imho also should not).

Your example is very obviously non-compatible with each other. Also, nothing
breaks if the program ignores the 'wrong' option (w.r.t. the user expectations,
that is).
A larger portion of these mutual exclusive options are not so easy to spot, or
are easy to miss in the documentation.
That is why I believe a program should refuse contradictionary options.

On the other hand, that is just me. Others (you included) do not agree with me.


So (and that's the real point afaik), the option processing toolkit should

1) _NOT_ make the choice (this holds at least both for Optik and argtools),
2) the toolkit should make it difficult to let ambiguities like this slip by
   without the programmer realizing (which does argtools better, because of the
   option-object = option-concept approach).

> Also, if options are to be taken from several places (configuration
> file, command line, etc.), what is the advantage to Optick or whatever
> in *knowing* this? Surely the aim should be to pass down arguments in

I am not entirely sure whether an option processing package should be capable
of handling options from various sources, but assuming that is indeed the case:

I consider

$ cmd --verify --noverify

different from

(configfile: --verify)

$ cmd --noverify

In the first case, the user specified (knowingly or not) an ambigious command
line. In the second case, the configfile states that 'verify' should be used,
but the user overrides that on the commandline, i.e. there is no ambiguity.

The implicit assumption in the second case is that options coming from the
configfile have a lower priority than options from the command line.
If I give that information to the option processing package, then the package
can differentiate between the first and the second case, and act differently
(for example, not generate an error in the second case).

Do note that at least argtools does not properly support the second case.
I think that Optik doesn't either (but look in the documentation if you really
want to know).

> I guess I'm saying that I believe we should clearly separate the "get
> options" part of the problem (which looks in the various places options
> might be and retrieves interesting stuff) from the "use options" part
> (which is given the information therefrom and does something with it). I

I agree. I am not even considering usage other than the ability to pull the
results of option processing from the option objects (in the case of argtools).

> would then see having two modes of input to the latter - the first

You mean 'former', the "get options" part ????!!

> (configuration file oriented) says "here is an individual option and its
> value", and the second (for ease of command line handling) says "here is
> a command line [1]_, please use it".
>
> .. [1] I'm agnostic over whether "command line" means
>    "sequence of 'words'" or "string to be broken up at
>    appropriate delimitors".

In fact, the command line is already broken up in pieces before it is delivered
to the program.


Albert
-- 
Constructing a computer program is like writing a painting