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

[A.T. Hofkamp]

On Fri, 8 Mar 2002, David Boddie wrote:

> > that and that program also do it', or 'because that is what my option
> > processing package assumes', not because they know it is the best approach.
>
> I imagine that in many cases the syntax for the arguments passed to the
> program is dictated both by the ease of parsing those arguments and the
> type of functionality offered by the program. Therefore, I suspect that
> we see something of the internal operation of utilities such as "tar"
> and "rpm" in their syntax definitions.

That may be the case. Anyway, they considered it the best reachable solution
(which may be different from _KNOWING_ the best approach).

> We give the parser the ability to parse different styles of command lines.

Good. I haven't yet seen that here (or maybe I wasn't looking). Can you give a
better explanation of this interesting subject ?
How can we specify this in a enough generic way ?

> > 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.
>
> I agree. We are in danger of rewriting options packages to deal with many
> special cases rather than addressing the more general problem.

I agree (obviously :-) ).

> Indeed, in the cvs-like case, the complexity of the command line syntax
> is being "passed upwards" to the programmer, who then may have to perform
> simple syntax checking on command lines.

I am not entirely sure whether that can be eliminated completely, but at least
an attempt should be made.
In some sense, it can be compared with the "far pointers" in C/Pascal/etc
compilers on Windows systems in the 80's and 90's.

The problem is that Intel processors had(/s?) 2 different pointers. Pointers in
a segment (which are 16 bit), and pointers to anywhere (which are 32 bit).
The C language states that the compiler should hide implementation details.
What Microsoft and Borland did was to base their entire compiler on the use of
segments, and introduce a 'far' keyword for 32bit pointers.
Effectively, they dumped the entire segment mess of the Intel processors on
their users.
Amazingly, users accepted this "extension".
I still consider it very good marketing to trick compiler users into handling
messy processor details that should have been hidden by the compiler
implementation.

To prevent such mess, I think that the work-around is not solution. If we want
to be able to handle cvs-like commands (like Greg says he wants to), we should
get a proper solution.

> We need to specify our requirements for such a solution, but not make it
> too general.

I agree there is a danger of becoming too general. However, I also think we
haven't yet reached that point. My 'generic solution' clearly eliminates some
limitations that Optik has. When we re-structure code without an improvement in
usefulness, we should start worrying... :-)

> With command line styles you could allow "verbose", "-verbose" or
> "--verbose", but a mixture of these might prove problematic. You could
> equally well allow both "-v" and "+v" and have them mean the same thing,
> or different things.

He, +v is new. Can Optik do that ?

I think it is not our job to define what a programmer can or cannot do. Given
the huge changes in computing, who knows what programmers can and want tomorrow ?

> > * 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.
>
> Without special characters to denote options, parsing would be slightly
> more difficult in this case. I imagine that the position of the options
> is important in the case of "tar", so it may be a special case command
> line with positional options/commands.

I don't really agree with the example. I only mention it here because it _can_
be handled without too much trouble, while the general opinion here recently
was that that example would be impossible to handle.

> Certainly, in extreme cases of this sort of command line, there is plenty
> of scope for ambiguity.

Yes, and users and programmers do not seem to be bothered by it.
This is also where I consider documentation very important. For example, we can
support optional arguments or optional dashes, but add a warning "this may be
dangerous, because ....". The programmer can then decide whether he considers
that convincing enough to search for a different solution.

> > 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.
>
> I think that we should be clear on what an option processing package
> should contain, and make it sufficiently modular to allow users to
> leave out or replace features they don't want or need.

I agree completely. Especially getting as specific as possible for "the common
case" is important.

> The first feature would resolve any debate over the preferred style of
> command line to support. It would leave only a debate on what should be

I currently don't know how to specify something like that. Estimating the
impact is even more difficult.

We should also consider platform-specific issues. For example, can and should
we handle the Windows-style of options, and/or the Mac-style (if it has one) ?

> I haven't seen much enthusiasm for the second feature so far, although I
> would find it quite useful. It would allow one-shot parsing which
> produces either a collection of values or an exception, depending on
> whether a successful match was found.

I don't know whether it would not be too complex. The most extreme solution
would be to have a scanner and a parser, and consider the command line a
sentence in a language. For option processing, I think that solution is
somewhat wildly outside what we want.

Can you see a cheaper solution ?


> Although I don't have the time to compare lots of libraries, I appreciate
> the discussion of ideas. I feel that without discussion we could end up
> with a library which suits a particular way of thinking without solving
> some of the more fundamental problems involving command lines.
>
> This wouldn't be too bad, but I'm sure that many people would then go
> back to writing their own parsers as a result.

That is what you can see happening. Why else is getopt still the standard ?
(not only in Python, but also in e.g. C or C++).

Unless we close the gap between what option packages deliver and what
programmers need, our solution is "just another option processing package".


> > 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.
>
> I believe that we shouldn't build an option processing package on a case
> by case basis.

I agree, we should look at the big picture, and try to capture the general
case. However, cases are useful for examples.


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