Support common '--' notation

[wernight]

Having '-help' isn't common, it should mean '-h -e -l -p' wereas '--help' should be the long form.

[adrianaisemberg]

True. This isn't common, however, changing this will not only break existing code (which may be acceptable in some cases, using the [Obsolete] attribute for example), it will break existing apps. Breaking existing apps affects users of the app instead of developers and this is not acceptable.
For example, if one has a script with the following lines:

myexe login -user=john -pass=foobar

Unless a developer updates the myexe code, the script will no longer work.

Thanks for the suggestion. I may consider a "CLAP2" and have this supported.

[wernight]

I agree. First I forgot another benefit: The arguments end market: mycmd --foo foo -- --this-is-a-file -another-one

There are still solutions:

1. Flag to support "-help" => "-h -e -l -p"
2. Major version with clear backward incompatible changes (much cleaner).

[adrianaisemberg]

Can you please elaborate more on the "end market" you mentioned?
I'm not sure I understand this line:
mycmd --foo foo -- --this-is-a-file -another-one

[wernight]

Everything after a " -- " will never be interpreted as a named parameter. Other than that, it has no effect.

For example both are equivalent:

mycmd --arg1 ok foo-file bar-file 
mycmd --arg1 ok -- foo-file bar-file 

It's useful when you want to make sure that file names that possibly start by "-" or "--" will not be interpreted as optional parameter values. For example this is different

mycmd --arg1 ok --arg1      # Interpreted as argument named "arg1"
mycmd --arg1 ok -- --arg1   # Interpreted as unnamed argument "--arg1"

It might not seem that useful at first but for example I use msysgit on Windows. Meaning I can call: find ... | xargs mycmd -arg1 ok -- which would be safer.

NDesk.Options supports that notation.

[alexanderfast]

I would also like to see this.

Or rather the full GNU style standard since I'm porting some Unix based tools to .Net and need to follow that convention. But I'm putting this here rather than creating a new issue. The minimum would be:

--long-option   # for long option names
-s              # for short option names
-abc            # for multiple short options without arguments (one character per option)
-s arg          # short option with argument
--long arg      # long option with argument

I found this project when looking for a verb based parser since I also need to be able to do something like git or mercurial:

git [verb] [verb specific options]

If you want, you could check the gnu getopt documentation although I personally find the POSIX specification a bit easier to digest.

You have some great code going on here. Maybe it would be enough to create an alternate parser with different rules. Besides, the default behavior can remain totally the same so no implementations are broken.

Would you be interested in any contributions regarding this?

[adrianaisemberg]

It was a long time since my last contribution to the project. I actually considered it "done" (only bug fixing).
Answering your question - yes, I would very much be interested in any contributions.

Thanks,
Adrian