You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Consider this Options class:
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 isCategories = ["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:
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.
The text was updated successfully, but these errors were encountered: