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.39k stars 381 forks source link

For some options, errors in the parse result results in their associated actions instead of ParseErrorAction #2498

Open barrygiles opened 2 days ago

barrygiles commented 2 days ago

I expect this is by design but was a surprise to me and I don't fully understand the motivations behind it.

Passing an additional parameter to a sub command results in an error in the parse result and a ParseErrorAction, which when invoked, prints out the error.

Passing an additional parameter to --version or --help also results in an error in the parse result, but the action is HelpAction or VersionOptionAction, which either prints help or the version without any mention of the parse error.

This seems inconsistent to me, but I'm guessing there might be conventions around this I'm not aware of. I could probably intercept the parse result in these circumstances and invoke a manually created ParseErrorAction or something similar, but this might be a bit messy and might be unnecessary if there are good reasons to stick with this behaviour.

Using System.CommandLine 2.0.0-beta4.24324.3.

KalleOlaviNiemitalo commented 1 day ago

Seems consistent with GNU diffutils at least:

$ diff a b c d
diff: extra operand 'c'
diff: Try 'diff --help' for more information.
$ diff a b c d --help
Usage: diff [OPTION]... FILES
Compare FILES line by line.
[…]