Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sequences with separators, if a separator is provided on the command line, should STOP at the separator #687

Closed
rmunn opened this issue Aug 20, 2020 · 1 comment

Comments

@rmunn
Copy link
Contributor

rmunn commented Aug 20, 2020

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.

@rmunn
Copy link
Contributor Author

rmunn commented Aug 20, 2020

Fixed by #684.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant