Add option name abbreviation (startswith) support (Off by default)

[MarkMichaelis]

Allow the end user to specify option names that are abbreviations (startswith) the actual option name as long as they are unambiguous. This option should be off by default.
(PowerShell supports this capability)

[KalleOlaviNiemitalo]

GNU getopt_long likewise has this capability.

[jonsequitur]

GNU and PowerShell command line syntaxes are strict enough to support this without ambiguity. System.CommandLine supports a superset of those syntaxes as well as Windows-style /-prefixed options.

It's definitely possible that System.CommandLine could support this behavior as well. Some analysis would be needed.

[KalleOlaviNiemitalo]

Related to #1860; if all tokens that start with -- were reserved for options, then it would be possible to treat them as abbreviations.

[KalleOlaviNiemitalo]

If individual aliases could be hidden (#1859), then application developers could use that as a workaround; just define every unambiguous prefix as an alias.

That could even be automated such that the application only needs to call one extra method on the root command to walk the command tree and add the aliases. Such an implementation would be be difficult for a System.CommandLine source generator to understand, though.

[jonsequitur]

The parser can probably handle the ambiguities. (I won't comment on the performance implications.) One question I had was whether users will understand some of the extra complexity.

Here's an example, which is pretty contrived, but I bear with me as I think out loud.

Given a parser configuration like this:

var root = new RootCommand
{
  new Option<bool>("abc")
  new Argument<string>("the-argument")
  {
    Arity = ArgumentArity.ZeroOrOne  
  }
};

If a user runs this:

myapp a

then a would match the option and not the argument. They have to know to escape it and have to know to use the POSIX -- to do so:

mapp -- a

My example is an edge case because non-prefixed options are very uncommon. We're not opinionated about prefixes because:

• - means something different in PowerShell than it means in POSIX
• / is a common Windows command line prefix

Which gets us to:

if all tokens that start with -- were reserved for options

This is a good suggestion and it would make the problem more tractable, and we could address #1860 as you say.

We could add that the abbreviation behavior wouldn't apply to tokens without one of the well-known prefixes (-, --, /).

This would change the design intent a little, from "We're not opinionated about prefixes" to "We recognize standard prefixes but don't enforce that you use them."

I think this would move us closer to user expectations, which is good.

The next question is whether these would represent parse errors:

Given this parser:

var root = new RootCommand
{
  new Argument<string>("the-argument")
};

Would any or all of these be errors?

myapp --arg
myapp -a
myapp /a

[KalleOlaviNiemitalo]

myapp /a cannot be an error, as that is the way to specify a file in the POSIX root directory.

For me, it would be fine if CommandLineConfiguration (or Command?) had some bool SwitcharDash setting. When true, ThrowIfInvalid could also insist that every name and alias of every option starts with a dash.

[KalleOlaviNiemitalo]

System.CommandLine supports a superset of those syntaxes

I'm not sure what that statement means mathematically. Are these sets of formal languages, such that each library can be configured to decide whether a given command line is a well-formed formula in the language?

[jonsequitur]

I'm not sure what that statement means mathematically. Are these sets of formal languages, such that each library can be configured to decide whether a given command line is a well-formed formula in the language?

What I mean is that each of GNU/POSIX, Windows command line, and PowerShell has its own syntax, each with one or more structures that are unrecognized, illegal, or impractical in the others. This mostly shows up in prefixes that indicate that a token is an option. In the case of -, both POSIX and PowerShell use it, but assign different meanings to it. These different syntaxes also allow different separators between an option name token (i.e. option token like -x) and its argument, and of course POSIX also lets you skip the separator (-xvalue).

In addition to those fairly well-defined rules, there are a large number of command line tools, many well-established, that have their own syntaxes that differ in significant ways from all of those. And when it comes to arguments, there are many subgrammars out there, often custom, which have the potential to introduce escaping needs so values can be disambiguated from option name tokens. This is a great example:

myapp /a cannot be an error, as that is the way to specify a file in the POSIX root directory.

System.CommandLine has a goal of being relaxed enough about these rules to be able to parse all of these major syntaxes. We want people to be able to use it without having to make breaking changes to their CLI and we want it to work for POSIX and Windows command lines.