search

dotnet / command-line-api

Command line parsing, invocation, and rendering of terminal output.
https://github.com/dotnet/command-line-api/wiki
MIT License
3.35k stars 375 forks source link

[Design] Powderhouse parsing subtleties #2393

Open KathleenDollard opened 2 months ago

KathleenDollard commented 2 months ago

As the Powderhouse core parser moves into the BCL, the parsing choices will made will become common across .NET applications. Supplying this consistency is a prime goal of providing a core parser layer. There is tension between the simplest behavior for end users, flexibility for CLI authors, and absolute correctness.

This a tracking issue to collect specific issues and reference the behavior of other systems to help nail down recommendations that we will take through the .NET API review process. Further comments on the challenges appear below the issues:

[ ] Is CLI syntax treated as case sensitive? #2394 [ ] Does Posix bundling loses to explicit options? #2395 [ ] Can arguments can appear after options? #2396 [ ] Are multiple arguments per option token are supported for collections? #2397 [ ] Are multiple option tokens are supported for single value options (last one wins)? #2398 [ ] Do we retain current -- behavior (.NET CLI may be nonstandard)? #2399 [ ] Is any syntax (like punctuation) is allowed for options? #2400 [ ] Is any syntax (like punctuation) is allowed for commands? #2401

Where Posix standards express an opinion, we will use that opinion unless there is a good reason not to.

System.CommandLine established standards, primarily based on correctness and flexibility. Providing flexibility to CLI authors results in inconsistency for end users. An example is AllowMultipleArgumentsPerToken. Changes from System.CommandLine behavior need to balance against breaking existing CLI scripts.

Some common Posix behavior is unexpected by end users, especially users with a strong Windows background.

This a tracking issue to collect specific issues and reference the behavior of other systems to help nail down recommendations that we will take through the .NET API review process.

Please limit discussion on specific issues to those issues.

KalleOlaviNiemitalo commented 2 months ago

For example, git expects options to follow arguments, while many other CLIs do not.

No, options in Git must generally precede arguments such as pathspecs:

$ git log Source/ --all
fatal: option '--all' must come before non-option arguments

The exception is that branch names and revision ranges can come before and between options (git log --no-merges master --date=iso).

KathleenDollard commented 2 months ago

Thanks, updated and cleaned up