Parser throws error if I use the option name put dont provide option value.

[NeelamTiwari24]

Example:

[Option('n', "name")]
string Name{get; set;}

If I run "Program.exe --name", it is not able to parse the arguments. I feel there should be a way to tell parser that option might come with no value.

[nemec]

What's the goal? Is it a state distinct from not including --name in the arguments at all?

[NeelamTiwari24]

Yes, I am calling my exe from a vsts task and "name" might be empty because user is supposed to fill that name. When the name is empty the call becomes like this "Program.exe --name --otherParam Value --anotherParam AnotherValue. But parser doesn't like it and throws error in this case. Is there a way I could tell parser that this is a possibility or my only solution is to write extra logic at vsts side to see if "name" is empty or not?

[lobster2012-user]

@nainat
Try --name ""
and see #412

[marcbarry]

@nemec

What's the goal? Is it a state distinct from not including --name in the arguments at all?

The goal is to allow software to fully capture a user's intention.

--license 1234 captures the argument value as supplied.
vs.
--license recognises that the user wants to be prompted to provide the value without placing it onto the command line. For example, the argument might be --password where by the user feels it is undesirable to expose a sensitive string to command line history.

The absence of an argument is not the same as an argument with no value.

@lobster2012-user - this is a good work around, but asking the user to provide an empty quote argument --name "" requires that user to understand the semantics of the command parsing library, which is poor practise and bad user experience. It should be possible for the user to indicate their intention via an argument, but pass no associated value.

Just as String.Empty signifies something different null, so does the presence of an argument without a value.

[lobster2012-user]

@marcbarry

This is a temporary solution.
For constant, it seems to me in #412 I suggested a fix. I don’t remember if it is connected.

[marcbarry]

Thanks @lobster2012-user - It took me a little while to understand #412, but it sounds like you proposed a change to the Regex.Match string in Tokenizer.cs#L193

The change hasn't been merged, and I'd prefer to avoid a fork of the project to resolve this issue.

The existing regex in Tokenizer.cs is "^([^=]+)=([^ ].*)$". This matches the "arg=value" pattern.

1. The first parenthesis group looks for characters other than =
2. Followed by a matching = character
3. Followed again by a second parenthesis group which matches any non space character.

It wasn't super clear, but after taking a closer look I think you had proposed to extend that second parenthesis group to also | match on [\\s] (where \s matches any white space including space, tab, form-feed, etc).

In order words to match any non space character OR to match any white space character ... which seems quite confusing to me.

I can see where you're coming from, but I don't think this is the right fix for this issue. Even if it were I'd be uncomfortable running off a forked version of the library, so I'd like to see a fix that the core developers are willing to merge.

I think the first step is to understand if the core developers agree this is a problem which they are willing to look at fixing. Can anybody comment on that?

[marcbarry]

I've done some further reading on this subject to see how the rest of the world handles this and putting some definitions on terms helped me somewhat.

• Positional arguments are bare values make.exe toast
• Named arguments are key value pairs make.exe toast count=2
• Options (or flags) make.exe toast count=2 --today or -t tomorrow

Command-line options may have arguments --output myfile.txt which are usually required by their option. I think what @nainat and I were asking for is that the option's presence still be noted even if the option's optional argument were omitted.

The problem with this it seams is that it introduces an ambiguity with positional arguments --output one two. Is one the argument of the --output option, or is it the first positional argument?

It seems then that this issue should be marked wontfix, and users should avoid such ambiguity by providing different options for "has-arguments" and "no-arguments" cases.

By way of example then to resolve the ambiguity from my given example

• The named argument --license 1234 would capture the value from the command line.
• The option -l would cause the application to prompt the user to provide the value.

[moh-hassan]

That is by design, any scalar option on the commandline should have a value, otherwise parser throw error 'missing value'.