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

[David Boddie]

On Tuesday 12 Mar 2002 5:07 pm, you wrote:
> On Fri, 8 Mar 2002, David Boddie wrote:

> > 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 ?

We can treat the command line input as having a particular style.
Options may begin with certain characters such as "-", the style may
allow "--" as well, and "-abc" may be automatically expanded to
"-a -b -c".

The style may forbid "-spam" as a single option called "spam", or allow
such options as in the style of the "xscreensaver-command" utility.

We can also specify a syntax definition in a number of styles, but that
might prove to be distracting, although it might be useful for certain
audiences. For example:

  Imagine a platform in which options are specified using the "/"
  character rather than the "-" character. A syntax string might
  be written for the benefit of the user as:
  
    Syntax: myscript infile /o outfile
  
  This is then interpreted in the same way as we might interpret
  
    Syntax: myscript infile -o outfile

> How can we specify this in a enough generic way ?

I think that a solution which is fairly specific to the command line
might be reasonably achieved by identifying the types of object which
are commonly found on command lines. Objects such as options, commands
and positional arguments tend to be treated differently, although in
some cases they may be equivalent.

> > 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 :-) ).

The agreement operator is commutative for this case. ;-)

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

I think that the use of a number of complementary libraries might be
useful in dealing with complexity. While one library may be unsuitable
for some tasks, another may be very good at exactly those kinds of tasks.

> 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 ?

The styles of command lines in use now may not change much in the
future, but it would be a brave person who suggests that they will
never change.

More interesting developments might come from the use of command line
syntax definitions to construct simple graphical user interfaces.
If this occurred automatically as a side effect of using the standard
library then non-command line users also benefit from the development
of command line applications.

I'm not suggesting that this module should include this, but it is
interesting to consider the possibility.

> 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) ?

The "os" module might be the correct place for such information.
It could be useful to consider such a feature for the sake of native
users on any given platform.

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

For certain types of syntax, it would make life easier to have a library
deal with the structure of the syntax and extract values from the user
input. For the test case at

    http://www.python.org/sigs/getopt-sig/compare.html

a solution which just takes the options it finds is clearly going to be
less work. In fact, my original solution scaled very badly with
increasing numbers of consecutive optional arguments, so 14 consecutive
options was quite a challenge for it.

> Can you see a cheaper solution ?

The library might determine the location of positional arguments
automatically and treat the groups of options between them as
independent entities. This is more or less along the lines of earlier
suggestions except that the application programmer wouldn't have to
perform the necessary operations manually.

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

I agree completely.

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

We have to start somewhere, yes.

David

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________