Proposal to change the way shorthand command line arguments are parsed

[PonchoPowers]

At the moment, the way the command line arguments are parsed makes sense on Windows, however on nix, if you were to use -k1 as a command line argument, this would typically equate to -k -1 on a nix machine.

The change I propose will make the parsing more consistent with a *nix machine.

This would be a breaking change, which is limited to those using command line switches.

It would be good if when a single letter/number is used, instead of being mapped to a longer command line argument, it is instead mapped to a config setting.

So say for instance -v was mapped to: --Logging:LogLevel:Default=Trace

And -d was mapped to: --environment "Development"

Therefore, -vd, would be mapped to: --Logging:LogLevel:Default=Trace --environment "Development"

This would be much more in keeping with *nix machines.

[PonchoPowers]

A breaking change could be avoided come to think about it, if a 3rd parameter could be passed to CommandLineConfigurationExtensions.AddCommandLine allowing for single character flags to be mapped to a command line argument, so that -vd AnotherArg=test can be parsed correctly, this would prevent the ambiguity whereby -vd could be a shortand switch, or multiple shorthand switches.

[Tratcher]

Please move this to https://github.com/dotnet/command-line-api

[PonchoPowers]

This relates to the configuration though so should it be moved?

[Tratcher]

Ah, that one's over here: https://github.com/dotnet/runtime/blob/8b1a0c865799e45208dfa20f8b74e53e9c9c2484/src/libraries/Microsoft.Extensions.Configuration.CommandLine/src/CommandLineConfigurationExtensions.cs

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration See info in area-owners.md if you want to be subscribed.

Issue Details

---

At the moment, the way the command line arguments are parsed makes sense on Windows, however on *nix, if you were to use **-k1** as a command line argument, this would typically equate to `-k -1` on a *nix machine. The change I propose will make the parsing more consistent with a *nix machine. This would be a breaking change, which is limited to those using command line switches. It would be good if when a single letter/number is used, instead of being mapped to a longer command line argument, it is instead mapped to a config setting. So say for instance `-v` was mapped to: `--Logging:LogLevel:Default=Trace` And `-d` was mapped to: `--environment "Development"` Therefore, `-vd`, would be mapped to: `--Logging:LogLevel:Default=Trace --environment "Development"` This would be much more in keeping with *nix machines.

Author:	BonnieSoftware
Assignees:	-
Labels:	`untriaged`, `area-Extensions-Configuration`
Milestone:	-

[eerhardt]

Another possibility would be to add an option to

https://github.com/dotnet/runtime/blob/8b1a0c865799e45208dfa20f8b74e53e9c9c2484/src/libraries/Microsoft.Extensions.Configuration.CommandLine/src/CommandLineConfigurationSource.cs#L12-L22

Which would put it in this "PosixCompatible" mode. If someone wanted to opt in, they would use:

    IConfigurationBuilder configurationBuilder = ...;
    configurationBuilder.Add(new CommandLineConfigurationSource { Args = args, SwitchMappings = switchMappings, PosixCompatible = true });

Then we could optionally add the parameter to the convenience AddCommandLine method, which would set PosixCompatible (or whatever we called the option).

[PonchoPowers]

I'd prefer a more general solution that gives intent into what it is doing rather than using PosixCompatible as PosixCompatible does not really give any intent into what differs whether it is true or false.

[eerhardt]

@BonnieSoftware - Do you have a concrete proposal?