UnrecognizedArgumentHandling options are cheking in all commands

[danielmeza]

Describe the bug
Whe an app has sub commands like
app
|-> subcommandA
|-> subcommandB

if subcommand A has UnrecognizedArgumentHandling = UnrecognizedArgumentHandling.StopParsingAndCollect the app will throw and UnrecognizedCommandParsingException when I run app subcommandB --nissingParameter because subcommandB not allow unrecogized aruguments.

To Reproduce
Create the followin structure
app
|-> subcommandA
|-> subcommandB

Set UnrecognizedArgumentHandling = UnrecognizedArgumentHandling.StopParsingAndCollect to
app, subcommandA and let subcommandB without UnrecognizedArgumentHandling option.

Then run app subcommandA --missingArg
You will see an UnrecognizedCommandParsingException
Expected behavior
With he following app structure:
app
|-> subcommandA
|-> subcommandB

where subcommandA has UnrecognizedArgumentHandling = UnrecognizedArgumentHandling.StopParsingAndCollect then when a call to
app subcommandA the app should run the command not mater if subcommandB has not UnrecognizedArgumentHandling

In other words we should not check that if any command nas not UnrecognizedArgumentHandling we should only check if the matching command has the correct UnrecognizedArgumentHandling value

[scott-xu]

From reading the code, the parser settings are top-level only in 3.0.
https://github.com/natemcmaster/CommandLineUtils/blob/master/src/CommandLineUtils/Internal/CommandLineProcessor.cs#L25
I'd suggest adding a new Attribute named SubCommandAttribute. It is the same with CommandAttribute but removed UnrecognizedArgumentHandling and OptionNameValueSeparators

[danielmeza]

@scott-xu those options needs to be available for subcommands too, cause one subcommand can make restrict use of parameters, and other subcommand can allow extra parameters. So the point is when the validation of UnrecognizedArgumentHandling is made, this validation should be made only for the matching command respecting the UnrecognizedArgumentHandling behavior on that command. So I believe that the existing API is OK, but the validation process is not.

And I'm not say that SubCommandAttribute is a bad idea, but we need to fix the process before to implement new APIs.

[scott-xu]

Thoughts? @natemcmaster
f002442#diff-09048a96a9ec655fadf40771663d764f

[natemcmaster]

I think the real fix is to adds new concept, subparsers. The current design mixes too many responsibilities into the subcommand structure. The API isn’t designed to handle parser behavior which varies from subcommand to subcommand. If someone is interested in taking up this work, let’s design some API for how to separate CommandLineApplication’s parsing responsibilities into something that could be scoped per subcommand.

[scott-xu]

Note: the OptionNameValueSeparators also has the same problem. I fixed both in PR #371

[scott-xu]

My PR has no API change at all.
If the sub command's UnrecognizedArgumentHandling/OptionNameValueSeparators is not set, it will inherit the setting from parent. The root command will have the default value if not been set.