Open KathleenDollard opened 6 years ago
The sample project is an artifact of experimenting with how to implement the dotnet CLI's existing behavior and help formatting. There are probably a number of issues like this, which we can fix up.
Longer-term, I think a clearer set of samples and how-to documentation would be good to have and has been requested (#50).
I think it would be helpful to folks writing global commands.
I'm not sure this exact thing should be fixed. I'm still debating in my head. What reasons are there for matched square brackets that are NOT indicating optional text? Are there any characters other than square characters that are used to indicate optional?
Now that I understand it wasn't intended to work the way I expected, I'm unstuck. But that sample led to me wasting some time.
The only case where the parser parses the strings passed to any configuration methods to infer behavior is that of the Option
constructors, which split on the pipe character to get the list of aliases for the option. I think the "q[uiet]" notation only appeared in help text in the dotnet CLI. The parser doesn't assign special meaning to this.
That said, we could make something like this work. Similar to splitting on pipe characters for the option string, this seems to fall into a category of configuration-by-example. The configuration input is meant to look like the help output, making it potentially easier to understand how to configure the parser.
From the Dotnet Parser sample:
and passing the following args to the parser (like a parser in that example)
Expected behavior
The switch argument recognized and returned as the value.
Actual behavior
For the switch argument to be returned, it must be passed like:
This is consistent with the tests, not consistent with user expectations. From the test for AnyOneOf
Short term action
Mark that example as problematic
I think this also needs to be fixed.