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

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

> The library I uploaded tried to comply with these two points. I
> still think that such a design would be a good low level API allowing
> the most flexibility. A higher level API can then be built on top
> allowing for easier use for typical cases.