RE: [boost] Re: Command line syntaxes

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-23 15:03:20

From:	mfdylan [SMTP:dylan_at_[hidden]]
> 
> --- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> > 
> 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).

All of these should be configurable, ideally with one or more policy class.

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

I'd declare both invalid.  All options should appear before the arguments.
There's no ambiguity to resolve, then, and the parsing is simpler.

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

This is certainly worthwhile.  However, if the supported types were
configurable via policy classes, then it would really be up to the user.
You only have to provide support for just so much flexibility, though.  For
example, I don't think you'd want to allow a policy to control whether
arguments may intermingle with options; there's just too much trouble
figuring out how to type the command line correctly, let alone how to parse
it correctly.  OTOH, it would be perfectly reasonable to have a policy that
controls the various delimiters rather than forcing them to be from a
predefined set. (I'm including the character(s) that introduce an option as
well as those that may separate an option name from its value.)

Rob
Susquehanna International Group, LLP
http://www.sig.com