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
> would be usefull to discuss possible syntaxes and possible clashes
> them. I've written some initial implementation of the parsing
proper which is
> available at:
> http://groups.yahoo.com/group/boost/files/Command Line
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!).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk