Re: [boost] Re: Command line syntaxes

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-22 09:01:22

mfdylan wrote:

> > I think that in order to make progress with command line parsing
> > library, it would be usefull to discuss possible syntaxes and possible 
> > clashes between them. I've written some initial implementation of the
> > parsing proper which is 
> > available at:
> > http://groups.yahoo.com/group/boost/files/Command Line Parsing/cmdline.cpp

> I'm not clear on the need to distinguish between long and short
> option names.  What I would have is a 'minimum abbreviation length'
> setting, whereby you must have at least x unambiguous letters of the
> option name for it to be recognised.  Some software may wish to set
> this to 1, meaning that a single character is sufficient providing
> only one option name begins with that character.  A setting of '0'
> would mean no abbreviations are allowed.  cleartool (the Rational
> ClearCase command line utility) uses 3 as the minimum abbreviation,
> I've seen other software that uses 2.

Resonable.

> To me "parameter" is the wrong term, it is actually the option value
> (as opposed to the option name).

I don't especially like "parameter" myself, because it's not sufficiently 
semantically far from "argument". I'll try start using "option_value" instead.

> I don't like the name "add_option" - register_option or define_option
> would be preferable.

Don't have a strong opinion here.

> The default as far as '-' and '/' goes is for DOS programs to handle
> both interchangeably but for unix programs to only allow '-'.

I'll note this.

> Note that '+' is not uncommon either.

It easy enough to implement. Are you sure it's common enough to support it 
(especially regarding your proposal to keep the number of syntaxes to 
minimum).

> Can you specify that whitespace between the option name and value is
> required/disallowed/optional?  What about ':' and '='?

For long options you can have either space or '='. It is possible to allow 
each syntax individually. For short options value can be directly adjacent to 
the option or be in the same token. Again, each syntax is enabled 
individually. Concerning ':' we have the question of yet another syntax again.

> Optional stripping of quotes around option values would be nice,
> probably should be on be default.

Currently, this is implemented for assignments to strings only. Maybe, code 
that assigns values to variables should deal with it? On the other hand, 
quoting might be very usefull for user types and having to unquote everywhere 
is boring.
        
> Wildcard expansion is needed - it is a pain having to write code to
> do this for command interpreters that don't do it for you.  There's
> code to help with this in the files repository (file_finder.zip).

It is surely needed, but low-level parser  well live without it. It would be 
easy to glob filenames later.

> How do you handle "arguments" interspersed with "options"?  I would
> assume that if option 'x' requires a value then
>
> cmd -x 1 a -y
>
> means opt(-x 1) arg(a) opt(-y)

Yes.

> And if option 'x' has no value then it means
>
> opt(-x) arg(1) arg(a) opt(-y)
>

Yes.

> But if option 'x' has an optional value do you flag an 'ambiguous
> command line' error?  

No, I treat "1" as an option value. The main reason I can offer is that 
common usage is when options come first, and treating "1" as an value work 
good in this case.

> In fact optional values are pretty problematic

True! 
        
> because of this, probably why they're hardly ever used (I can't think
> of an application off the top of my head that supports one). 

I think I have an example. gcc accepts "-O" option and allows to specify 
"-O2". But I don't know of any example where optional value can reside in the 
next token.

> How do you specify that one of a set of options is required or that
> certain options are mutually exclusive?  Or this that expected to be
> dealt with at the application level?

Yes, or by the highest level of CLL. 

> To be honest I'm actually in favour of disallowing more obscure
> command-line syntaxes basically to encourage developers to stick to
> recognised conventions.  

I agree, but I think that syntaxes I've mentioned are quite common still. 

> It also simplifies both the interface and
> the implementation.  Writing a command-line argument parser that
> supports every existing style of command-line out there is not only
> virtually impossible but pointless (a quick look through the man page
> for HP's aCC compiler reveals at least 10 different styles of command-
> line usage all mixed together - any class that makes this easy is on
> the wrong track as far as I'm concerned!).

Truly, I would like just fine with unix style. People tend to want more 
flexibility, though.

- Volodya