Description
Consider this Options class:
public class OptionsWithSeparator
{
[Option('c', "categories", Separator = ',', HelpText = "Categories")]
public IEnumerable<string> Categories { get; set; }
[Value(0, HelpText = "File name")]
public string Filename { get; set; }
}What would you expect to get from the commandline myprog -c one,two filename.txt?
If you expect that to produce Categories = ["one", "two"], Filename = "filename.txt", I agree. But that's not what happens. What it currently produces is Categories = ["one", "two", "filename.txt"], Filename = null. This is caused by the fact that IEnumerable options try to grab every subsequent non-option argument that follows them, and only stops once another option has been encountered (or, if EnableDashDash is true and you're using the upcoming 2.9 release, once a -- argument has been encountered).
I believe that this is unintuitive behavior, and that what should happen with IEnumerable options is the following:
- If there is no separator given, grab all available non-option args
- If a separator is given, but the next non-option arg doesn't contain the separator, continue to grab all available non-option args
- If a separator is given, and the next non-option arg contains the separator, STOP and don't grab any further values (this would be new behavior)
Currently the code follows the first two of those rules, but not the third.
Here are bug reports that are ultimately caused by this overly-greedy grabbing of IEnumerables, which would have been solved by the behavior I listed above:
#91
#454
#510
#617
#619 (which can also be fixed by setting EnableDashDash = true, but it would also be fixed by the behavior I'm proposing here)
Clearly, users expect a separator, if provided, to confine the IEnumerable's "grabbing" to just the parameter containing the separator. I'll submit a PR soon to implement this behavior.