Re: Command line syntaxes

From: mfdylan (dylan_at_[hidden])
Date: 2002-01-21 23:27:36

--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> 
> I think that in order to make progress with command line parsing 
library, Iit 
> 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.

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

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

The default as far as '-' and '/' goes is for DOS programs to handle 
both interchangeably but for unix programs to only allow '-'.
Note that '+' is not uncommon either.

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

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

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

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)

And if option 'x' has no value then it means

opt(-x) arg(1) arg(a) opt(-y)

But if option 'x' has an optional value do you flag an 'ambiguous 
command line' error?  In fact optional values are pretty problematic 
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).

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?

To be honest I'm actually in favour of disallowing more obscure 
command-line syntaxes basically to encourage developers to stick to 
recognised conventions.  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!).

Dylan