[getopt-sig] More about commands on the command line

[A.T. Hofkamp]

On Fri, 8 Mar 2002, Russ Cox wrote:

> Subject: Re: [getopt-sig] More about commands on the command line

Wow, so many responses in so little time.

I tried to create some structure in the chaos last weekend, but it didn't
really work. The issues are too much inter-connected with each other.

So instead, I will simply answer to the replies when I consider it necessary.
Others, feel free to add or comment.

> > It is true that you can parse cvs-like command lines with multiple instances of
> > parser, but it is a work-around rather than a proper solution. I mean, you fix
> > the problem by writing a solution around the limitations of the option
> > processing package.
>
> This is where I think those who objected (and myself) differ with you.
> In my mind, CVS-like command lines are bad program design.  If you've

Most of us may think so (I am not sure what to think of it), but the fact is,
these programs are out there. At least the programmer considered their
interface the best feasible, and most people seem to be able to work with the
programs, and are not so annoyed that they modify the code.

The only conclusion that I can draw is that users can handle a lot of ambiguity
and (to us) crummy interfaces.

The next question is then obvious, should we ignore these programs and leave
the programmers on their own (i.e. have them start from scratch), or should we
try to structure the problem for them ?

Every option processing package I have seen until now does the former. They
implement the (easy) POSIX sub-set for what an option is, and totally ignore
the fact that a programmer has a much bigger problem (in fact, in some cases,
the command-line interface w.r.t. options is a very tiny problem).

I think that ignoring the bigger picture is exactly the reason why every option
processing package, except "getopt" fails to catch on.
"getopt", being the only extremely flexible solution fits in just about any
command line interface scheme, and is more or less the only option (excuse the
pun) left if the demands of the programmer are bigger than what an option
package delivers.

To overcome this problem, an option processing package has to extremely open
and modular, allowing it to be used partly, or in a way we will never think of.

> got multiple commands, give them multiple names.  I greatly dislike the
> idea that keyword early on changes the set of valid options later.  At least

You may think so, but I don't think that we as library designer can tell a
programmer what he should or should not do, especially in an open source
environment. It is much the same as when I would tell you to use for example
/bin/csh, because I think all the other shells are evil.
(I don't think that by the way).

The only thing that we can do here is give him the power to organize things in
his own way, and add a warning that he may be heading for trouble, because of
so and so.
In that way, you have warned him that it may not be wise to proceed, yet you
didn't limit him in doing it anyway.
Some programmers may 'make' it, they will produce something useful, which just
happens to be outside our norms. Others will fail, and get bitten by their own
creations.
I don't think that it is bad if programmers burn their hands when playing with
something powerful. If one is given power, one should respect it, and use it
properly. If you don't, you will get burned.
However, people (programmers included) cannot learn that if they are protected
from powerful stuff. They can only learn that by experience.


> > * With the work-around, command-line arguments near the end of the line are
> >   parsed/copied more than once. Not something you'd really want to have.
> >   We are lucky that Python shares (string) data, otherwise it would have been a
> >   potentially costly work-around.
>
> This is entirely untrue.  They don't get parsed more than once -- the first
> pass STOPS when it gets to the cvs command.

I phrased it sloppy I am afraid. What I meant to say was that, in order to
parse the remaining arguments, you need to create a 'new' command line for the
next parser instance. Thus, you have to copy all remaining elements in a new
list (and maybe do something special for the first element).

If you have a lot of commands, and thus a lot of sub-parse runs, you end up
creating a lot of lists. Clearly, the processing package should deliver a
one-shot parsing solution in these cases.

> > * With the equal status of commands and options, I can have commands that act
> >   as options, like 'cvs verbose commit'. Maybe this is not normal now, but can
> >   anybody give me a good reason why 'verbose' is bad, and '--verbose' or '-v'
> >   is not ? At least, 'verbose commit' looks more intuitive and less technical
> >   to me, which may be a + for non computer-experts (until now, I cannot give
> >   a good reason to such people why we need to write a '-' in front of options
> >   rather than my example).
>
> We are not debating how commands should work.

I don't entirely agree with you. The above is more or less excluded as
possibility because of assumptions of e.g. option processing packages. By
getting rid of these assumptions (or at least, making them explicit), people
may get new ideas or see new opportunities for implementing a better
command-interface.
I think that it is important that the option processing package should allow as
much styles as possible, even if they are currently not commonly used.

> rpm is awful too.  I'd like NOT to be able to handle such cases in the
> common case (I don't mind if there is a work around) so that we don't
> encourage such commands.

This may be the source of a lot of problems. I _NEVER_ said that I consider
stuff like cvs, tar or rpm THE COMMON CASE (though Greg does for cvs).

I think that Optik more or less covers the common case. However, what we are
going to deliver should be flexible enough to be useful in the non-common case
as well.

> Again, tar is nonstandard and is reasonable to require a nonstandard solution.
> The last thing we need is everyone implementing interfaces like tar.

I agree completely.

> Sooner or later, somebody will greatly abuse that power.

Yep, and we are not going to stop them. Any piece of useful software can be
abused. For example, I can use Python to compute 1+1.
Is that bad ?

No, in my opinion. Maybe the abuse is justified (e.g. I suddenly have a
extremely lack of confidence in the computing abilities of my computer).
Sometimes it is not. In the latter case, others will fix the problems (if the
abuser does not first). Like I said, you only learn to respect fire by
getting burned (quite literally, in this case).

> You're arguing for nonstandard things that only complicate
> stuff for the user.  It doesn't bother me at all that Optik (the

Nope, I extend the power for the non-common case.
There is a real important function for the documentation here. It should
clearly state the 3 levels of complexity:

1) iterator-like processing
2) the common case
3) anything beyond the common case.

Especially with 3, the manual should warn that the territory is potentionally
hazardous both for the programmer and the user.

I think we should try to reach agreement on
a) what exactly is in 'the common case' ?
b) what is in 3 ?
   (if you ask me, as much as possible, with the condition that as a programmer
    I should be able to use code from 1 and 2.)

> current proposal on the table), by side effect of its interface,
> makes these more or less impossible.

If that is the goal, we are wasting our time here. We can simply pick any
option processing package. I can also predict that it will fail, just like all
the other option processing packages that exist.

> If you want to do arbitrary parsing, use the iterator that I posted, perhaps
> invoking it multiple times.

I know, but that is too low level. If I decide (after much thinking) to write
code beyond the common case, I have a very complex problem.
Exactly in that case, I need all the help I can get.
So why is it then not possible to re-use the Option-object framework, exactly
at a moment I most need it ?

(and yes, these programs exist. look at distustils, cvs, tar, rpm, and probably
many others).


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