Sample for AnyOneOf doesn't work as expected
From the Dotnet Parser sample:
private static Option VerbosityOption() =>
Option("-v|--verbosity",
"Set the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]",
AnyOneOf("q[uiet]",
"m[inimal]",
"n[ormal]",
"d[etailed]"));
and passing the following args to the parser (like a parser in that example)
{ "--verbosity", "q"}
{ "--verbosity", "quiet"}
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:
{ "--verbosity", "q[uiet]"}
This is consistent with the tests, not consistent with user expectations. From the test for AnyOneOf
[Fact]
public void Applied_option_with_specific_arguments_does_not_accept_argument_that_does_not_match()
{
var option = Option("-x", "", AnyOneOf("one", "two", "three"));
Short term action
Mark that example as problematic
I think this also needs to be fixed.
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.