Re: arguments parsing, wildcard matcher

From: williamkempf_at_[hidden]
Date: 2001-11-28 12:08:27

--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> 
> > I U/L a command line parsing concept to the Files section some 
time
> > ago.  It's a raw parser with few bells and whistles, which seems 
to
> > not be what people want.  However, theres a few things I'd like to
> > say about it and would suggest anyone working on a library to do 
this
> > should look at the code.
> 
> Yep, absense of bells and whistles is what made me attempt writing 
my library.
> 
> > 1) A command line parser needs to be *extremely* flexible.  Most
> > libraries I've seen with easier and more OO APIs restrict you to 
the
> > simple format of:
> >
> > prog [options] [free arguments]
> >
> > Where typically the options can take a single argument or have 
some
> > issues with when/how multiple arguments for an option can be
> > specified.  A good parser should allow multiple arguments per 
option
> > as well as allowing free arguments to be interspersed within the
> > options.  This isn't an easy thing to do and is nearly impossible
> > with the simpler APIs.
> 
> AFAICT, the interface that I use for describing options syntax does 
not 
> preclude mutliple options at all. The only problem with 
interspersing options 
> and arguments is ambiguity arising with optional parameters.
> "--foo bar" can mean two different things if "foo" takes optional 
parameter. 
> Should we be greedy in this case?

I never looked at your implementation so I wasn't commenting directly 
on what you support or don't.  However, the ambiguity you point out 
above is precisely why I think we need the lower level interface as 
well.  In general interspersing options with arguments can't be done 
because of these ambiguities, and so higher level interfaces can't 
support this.  However, it's often possible to handle the ambiguities 
directly which is easily done using the interface in the code I 
uploaded.

> > 2) The "style" of the platform should be adhered to, unless
> > specifically specified to be different.  In other words, Unix 
folks
> > are used to -x and --xxxxx for short and long options, while 
Windows
> > folks are used to /x with various methods of handling long options
> > (/xxx with exact match or /xxx where as long as the subset of the
> > full long option character set is unique it's accepted, etc.).  
Also
> > Unix folks are used to case sensitive options, while Windows folks
> > frequently see both case sensitive and case insensitive options.
> > Unix folks expect --help while Windows folks expect /?.  Etc.
> 
> I have slightly different position. IMO, there should be one 
default style. 
> If developers want different style of different OSes, they pass 
some flags 
> explicitly. 

That's only slightly different then my position.  My position is that 
when I'm writing a program for platform X it should be EXTREMELY 
trivial to have the parser behave as if coded for that platform.  If 
I have to pass 3 or more options to make it behave this way then the 
library is getting in my way.  That doesn't mean that I expect the 
program to take / as the argument on Windows but - and -- on Unix.  
Portable programs should pick a style and use it consistently on all 
platforms.
 
Bill Kempf