Feature request: Match commands by prefix

[alexrp]

Many interactive programs will match commands by prefix. In GDB for example, dis, disas, disassem, etc are all equivalent to disassemble. Having an out-of-the-box option that could enable this command matching behavior would make the experience of using System.CommandLine for such scenarios much smoother. I imagine it could be implemented as a middleware function.

[jonsequitur]

We discussed this at one point and I think it would be very useful, but complex enough that we didn't take it on.

Some thoughts:

• The middleware pipeline is invoked after parsing is complete, so this would most likely need to be implemented within the parser itself.

• If a parser is very strict about ordering, this is straightforward. For example, given root command root which accepts arguments as well as two subcommands subOne and subTwo, this input would unambiguously be an invocation of root subOne:

  > root subO sub

  But System.CommandLine allows parent commands' arguments to come before or after subcommands, so the following are both valid invocations of subOne, with sub as an argument to root:

  > root subOne sub 
  > root sub subOne 

  This was done in originally to support the existing grammar of the dotnet CLI and be flexible enough to handle similar cases in other tools.

• Using the same example CLI, the following would also be ambiguous if root allows direct invocation, i.e. a subcommand is not required.

  > root subO

  Is this invoking the subO subcommand or passing subO as an argument to root? If the former, how could a user do the latter?

• Command lines are typically used in one of two different contexts: interactive and scripting. For scripting, people often advocate using long forms instead of shorter aliases because the long forms are more intention-revealing. So the use case for this feature would be for interactive usage rather than scripting, which is how I understood the feature request. Our conjecture was that by making tab completion ubiquitous, we provide similar convenience while keeping the parser a little more flexible with regard to ordering, and a little less ambiguous.

All that is to say that I think this can be done and would be a good feature but we'd need to think through whether the previous design decisions allow it. If we can't figure that out, it might be a worthwhile area to direct our usability study, to determine whether we made the right call.

@KathleenDollard