Parser does not display an error when we specify an argument without its value about commandline

[gsscoder]

Hi, the problem could be about the wrong specification of the output stream for error reporting.

When you create the CommandLineParser please specify Console.Error. It follows an example:
var parser = new CommandLineParser(new CommandLineParserSettings(Console.Error));

You can also use the default singleton instance that uses Console.Error by default:
var result = CommandLineParser.Default.ParseArguments(...);

If this doesn't solve this issue, please post a more complete source (or a link to a public download) to repeat the problem.

Regards, Giacomo

[alexanderfast]

I've also seen this. I'm working on a patch so you'll probably see a pull request soon. But here's a Gist that illustrates the problem.

[alexanderfast]

Well look at that GitHub found my commit anyway. I'll wait a little with making a pull request then.

You can probably see where I was going with the code. A HasValue method has been added, but it currently only works for nullable types. So while it doesn't solve the case of int it would print an error if the option type was int?, or any other type with null as default value.

I thought about adding a specific error string for this but went for simplicity.

[gsscoder]

Mmmm... I see. Thank you for the Gist source.

args = "".Split(); // prints true and no help text

I think that at least this one is correct because '-z|--zzz' option is not required.

args = "-z 0".Split(); // prints true and no help text

Also this is correct for the parser. It's equal to invoke 'yourapp -z 0'. Why it should be false with help text and errors?

args = "-z".Split(); // prints false and help text, but no errors

I'll start work with this one. False returned is correct but '-z|--zzz' is not boolean so an error should be built...

News A.S.A.P.!

Regards, Giacomo

[alexanderfast]

The gist was more about showing the different combinations, with the result in comments for reference. It wasn't my intention to label them right or wrong. Though I agree with you, the first two are correct, the third one should print an error.

I don't know if you've had any time to look at the commit I made. I've been thinking about ways to write a unit test for it but the parser errors aren't really exposed. And doing string searches on the output written doesn't seem like a good approach.

[grigmin]

thanks guys
i look forward to the fix.
this parser looks great. i'm starting to replacing all the in house one we built over the years with this one. it will make our job much easier. :)

[alexanderfast]

@jandler create a fork and join the fun :)

[alexanderfast]

I would like to see this issue resolved. Take a look at the referencing commit. Thats a unit test which currently fails.

[gsscoder]

Thanks, I'm working on the project right now!

I'll copy & past after leaving this thread, expect a commit ASAP.

[alexanderfast]

I would guess that the fix for this bug involves adding a new property to the ParsingError class. Maybe its time to remove the properties from that class and create one class per error? This will probably make it easier to add new errors. And the boolean properties seems to be mutually exclusive anyway.

[gsscoder]

I've solved adding a property to OptionInfo to know if the value was set.

This issue is about a non-boolean required option. You can define it, left it without value -> but it still required!

This arise another problem... If an option is Required it MUST not have default value (this not impact the fix) but how do you set a default for a required? Make no sense.

Agree?

[alexanderfast]

An required option having its default value is fine, as long as it has a value. For me, the important part of the fix is when the user defined an option but didnt define its value (applies to only non-bool properties).

[gsscoder]

Check it out... Anyway new test pass (I'd like to write coverage on the subject).

Thanks for help!