Re: arguments parsing, wildcard matcher

From: williamkempf_at_[hidden]
Date: 2001-11-29 10:37:16

--- In boost_at_y..., christian.engstrom_at_g... wrote:
> >  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. 
> 
> One possible way of resolving this particular ambiguity is to let 
the 
> command line parser impose the syntax rule that if an option takes 
an 
> argument, there must be an "=" sign between the option name and the 
> argument.  This would mean that "--foo = bar" is always an option 
> with an argument, whereas "--foo bar" is always an option and a 
> parameter.

This means that you can't have an option that takes multiple 
parameters:

--foo bar1 bar2

You can get tricky with the parsing by also requiring commas between 
parameters:

--foo=bar1,bar2

But now the syntax is becoming foreign to most users.  I'm not sure I 
like that.

> This syntax rule is consistent with how most programs work under MS-
> DOS, and is also consistent with how for instance Emacs handles 
(most 
> of its) long options.  While it may not be consistent with how most 
> Unix programs presently handle short options, it wouldn't do any 
harm 
> to the legibility there either, IMO.

Under most DOS programs I've used the '=' is an optional syntax.  In 
other words both of these are legit:

/foo=bar
/foo bar

Bill Kempf