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

[Russ Cox]

> 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
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
in the case of CVS, the split between general options and command options
is clear, because you've got this thing that is definitely not an option 
sitting there.  Letting actual options behave this way is a terrible idea.

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

> * 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.
We are trying to agree on an interface for a standard
option parser.  If you want to build something else
entirely, go ahead, but you've gone away from options now.
All you're doing is pointing out how crummy cvs is,
which I won't argue against.  Try doing this to ls and
you'll see where it falls apart.

> * With the equal status of commands and options, I can have options that act as
>   commands, like 'rpm -q' and 'rpm -i'. This even works with command lines like
>   'rpm -qp mypackage.rpm'.
>   I'd like to see you handle such cases with the current option processing
>   packages.

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.

> * With the equal status of commands and options, I can have optional dashes,
>   like in 'tar xzf myfile.tgz'. Not pretty and not recommanded, but it fits in
>   my solution without major head aches.

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

> * With my generic solution, the only difference that remains between options
>   and commands is the magic involved in decoding stuff like '-spam'. I find
>   this strange. Why is there no such magic with commands ?

Because commands are not options.  And too many programs have
adopted this weird long-options-with-single-dash syntax.

> I consider it advantageous to have the more generic solution. I learned a few
> things, and I have more power to do things like I want rather than being forced
> by the option processing package.
> Sooner or later, somebody will need that power.

Sooner or later, somebody will greatly abuse that power.
You're arguing for nonstandard things that only complicate
stuff for the user.  It doesn't bother me at all that Optik (the
current proposal on the table), by side effect of its interface,
makes these more or less impossible.

> The discussion of what should and should not be part of the option processing
> package is a seperate discussion to me. I can imagine that my generic aproach
> looks very wild, and seems to be wildly outside what is considered 'option
> processing'. On the other hand, there does seem to be a need for something
> stronger than what e.g. Optik delivers by default. That 'something stronger' is
> currently in the form of a work-around, which happens to function for some
> cases (like cvs). It does not handle all cases, and neither is there any hope
> that it ever will in its current form.

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

Russ