Consider optional case insensitive parsing

[jonsequitur]

Developers should have the option to create command lines where commands and options are matched in a case insensitive manner. This matches existing expectations for PowerShell users, and even for POSIX users, this may make it easier for them to do the right thing.

[KathleenDollard]

I think this is a good idea and we should continue to get feedback on it.

My windows Command Prompt initial mindset (where I internalized CLI years ago) is definitely case insensitive.

[jonsequitur]

As I posted on #969, it's not clear to me that we should do this. Command lines are typically case sensitive on Linux/macOS, and often on Windows as well. Could case insensitivity lead to an inconsistent ecosystem that will confuse people? When I'm using a new command line tool, how will I know whether it's case sensitive or not?

[baochenw]

How about give more flexibility to let the consumer decide it? Maybe, theirs command lines are cross platform. And also maybe theirs are windows only. Even theirs existing apps are case insensitive and would like to move to this great package.
We are encouraging making the command lines case sensitive. I'm not sure if MSFT will change cmd and powershell to case sensitive.
For some reason, if they want to make theirs command lines case insensitive but we don't support it. Ultimately, they will look for other solutions which support that but don't change theirs idea.

[Keboo]

If we allow case insensitive matching, that that opens up the possibility of an invocation failing do to an ambiguous match. That is, when there are more than one possible symbols could potentially match a given token.
A few things worth discussing further:

• How would case insensitivity be toggled? If it is controlled by the developer this could simply be an API addition. If this were control by the CLI consumer, it would likely need to be controlled by something like a directive.
• How to handle error caused by case insensitive matching? I suspect this would need to be handled in a similar manner to an existing parse error, with some message indicating that it failed due to matching multiple symbols.
• How to handle posix bundling? Right now we support bundling of arguments, allowing case insensitive matching adds additional complexity here.
• How to handle symbol matching? Unforuently this is not always simple with nested commands since items may be specified in any order. Should it be consider ambiguous if there is a case-insensitive match on the current command, but an exact match on a parent command?

[elgonzo]

I would very much like to see providing the developer with a choice of whether they want their CLI to behave in a case-sensitive or in a case-insensitive manner. I prefer using camelCase or PascalCase for (longer) option names, even when also employing kebab-case, as i find this more readable in the help dump than using snake-case or kebab-case alone. But i do not want to burden the user with painstakingly observing and obeying the letter case.

While i have no deeper insight into where and what a good API for such a choice should look like, i feel like CommandLineConfiguration and CommandLineBuilder (through a Use* extension method) could be good candidates for offering such a choice to a developer employing System.CommandLine.

If we allow case insensitive matching, that that opens up the possibility of an invocation failing do to an ambiguous match. That is, when there are more than one possible symbols could potentially match a given token.

How and where do you see case-insensitivity introducing additional ambiguity? In a case-insensitive mode, the options -c and -C would be equivalent. Having a case-insensitive CLI that has to parse -c -C or posix-bundled -cC would be no different than having a case-sensitive CLI that has to parse -c -c or -cc. System.Commandline already has to deal with the latter, so dealing with the former should be exactly the same thing but based on StringComparer.OrdinalIgnoreCase-based comparisons and lookups. (Or perhaps StringComparer.InvariantCultureIgnoreCase; i don't know what would be the wiser choice if some developer chooses to define option names with non-latin letters.)

• How would case insensitivity be toggled? If it is controlled by the developer this could simply be an API addition. If this were control by the CLI consumer, it would likely need to be controlled by something like a directive.

In my opinion, the choice and ability to enable case-sensitivity should rest in the hands of the developer only. The developer either designs their CLI to function in a case-insensitive manner, or they don't.

If the CLI is not designed to be case-insensitive, what would be the consequences of the CLI consumer being able to enable case-insensitive parsing through a directive or other mechanism? Doing so would put a burden on the consumer of the CLI to verify that the CLI would still operate in the same way and does not exhibit unforeseen and unexpected changes in the behavior. That would be a pretty though ask for the conumer of the CLI.

On the other hand, if the CLI is expressly designed and behaves in case-insensitive manner to begin with, what would be the actual point of a consumer of the CLI being able to enable case-sensitive mode?

• How to handle error caused by case insensitive matching? I suspect this would need to be handled in a similar manner to an existing parse error, with some message indicating that it failed due to matching multiple symbols.

Since in case-insensitive mode, -c and -C would be equivalent, defining an option for -c and an option for -C for a case-insensitive CLI should be treated exactly like a developer defining the option -c twice (a situation which System.Commandline already handles).

• How to handle posix bundling? Right now we support bundling of arguments, allowing case insensitive matching adds additional complexity here.

Where and what is the nature of the additional complexity you see? In case-insensitive mode, a bundle like "-abcCD" would be equivalent to "-abccd" (and which System.Commandline is already able to handle).

• How to handle symbol matching? Unforuently this is not always simple with nested commands since items may be specified in any order. Should it be consider ambiguous if there is a case-insensitive match on the current command, but an exact match on a parent command?

Don't (re)introduce case-sensitive behavior if the developer has expressly chosen case-insensitive behavior. If a parent command and a sub command feature options with names that only differ in their letter case, then treat those options as having the same name when in case-insensitive mode.

[jonsequitur]

I think the previous comments assumed this would be an end user decision and not a developer decision. I think each approach has its own problems.

For example, possible ambiguities arise if the end user can toggle this setting. We would need a mechanism (preferably at design time, to avoid a perf hit on every run) to ensure that a given configuration would be valid in case-insensitive mode.

If this is a developer decision, on the other hand, how will users know whether a given command line is case sensitive? Will it be confusing for macOS / *nix users to encounter case insensitive command lines?

[Pxtl]

I just hit this. I'm trying to modernize an internal application where its previous command-line parser was a NIH homebrew, and my users expect case-insensitivity. This is a show-stopper.

To my mind, each alias should be defineable as case-sensitive or not, so that single-character aliases can be case-sensitive in their crowded space, but long verbose commands don't need to be.

Honeslty, I'm surprised even this lib is so standardized on the double-hyphen prefix. I'd assume it would have me pick the identifiers and then use whatever prefixing characters are native to the platform.

[jonsequitur]

each alias should be defineable as case-sensitive or not, so that single-character aliases can be case-sensitive in their crowded space, but long verbose commands don't need to be.

You can do this currently by specifying the additional aliases:

var option = new Option<string>(new [] { "-a", "-A" });

I'd assume it would have me pick the identifiers and then use whatever prefixing characters are native to the platform.

Most of our examples use POSIX-style prefixes but you can absolutely choose the prefixes you like. The System.CommandLine HelpOption includes both styles:

command-line-api/src/System.CommandLine/Help/HelpOption.cs

Lines 8 to 14 in 3e11e14

	public HelpOption() : base(new[]
	{
	"-h",
	"/h",
	"--help",
	"-?",
	"/?"

The .NET command line ecosystem has been trending toward broader use of POSIX for several years, not least because .NET Core tools are cross-platform, and on non-Windows systems, the / character conflicts with file path separators. Consistency across operating systems helps reuse of documentation, script code, and so on.

[Pxtl]

Ah, thanks for the clarification. Although by "conventions of the platform", I was thinking of how Powershell is pretty strongly on single-hyphen, not double-hyphen, for options. That's mostly what I had in mind, not the old slashes.

As for "using multiple cases as aliases" - I actually meant the reverse - that single-char aliases you'd want case-sensitivity there, but case-insensitivity would be more useful for long options where the user can't remember if it's StartDateTime or startDateTime or StartDatetime or startDatetime or startdatetime or what, and generating out every possible combination is non-trivial. And while I've been experimenting with autogenerating a suite of aliases for longer option-names, I found they made the "Help" screen unusable cluttered, unless there's a way to restrict "help" to only list certain aliases?