Show subcommand help when try_parse returns an error

[andrewring]

I'm using try_parse_from() on a derived Parser to make a repl style mode for a cli tool I've written. If I supply a subcommand, but not all the required arguments, the clap::error::Error's print() function outputs the root level help, rather than the subcommand help that would be shown if I parsed the same input using the normal parse(). Is there a way to get the subcommand help in this scenario?

edit: Hmm... it looks like subcommands aren't being parsed with a top level call to try_parse_from(), which implies the problem is not simply in the help, but something more being required...

[andrewring]

My problem stemmed from not having included the application name in the arguments, so there was an off by one issue with the indices when parsing. Prepending the name of the application to the subcommand list fixes both the help output and the functioning.

[epage]

See also #3675

[epage]

Could you provide feedback on

• the new repl example
• the last piece to figure out for stablization, I think

[andrewring]

Happy to. WRT repl example:

• The example is a bit different than my scenario, because I'm adding a repl mode to an existing tool. I'm also using the derive api, fwiw. This means that I don't have a subcommand for quit/exit, and do pre-checking before parsing. I would actually love to be able to have variants with +/- subcommands so the repl subcommand wouldn't show while in repl mode, and exit/quit would show... but I expect that would be hard to achieve in anything like a graceful way.
• This example doesn't take advantage of the colored output included in the help text... using err.print() would provide that.
• Using string comparison, rather than something like an enum for the subcommand is more likely to encounter typos. It also stops the use of an exhaustive match to provide compile-time feedback if a new command is added, but not implemented.

Multicall looks like it would be interesting if I could annotate some of the subcommands to be included in only some cases... that would provide the feature I mentioned above... I could use the prompt in place of the application name, and include quit/exit when the prompt is used, and while also leaving out the repl subcommand. That's a big if, though, and it's not clear if that's the intended functionality.

[epage]

The example is a bit different than my scenario, because I'm adding a repl mode to an existing tool. I'm also using the derive api, fwiw. This means that I don't have a subcommand for quit/exit, and do pre-checking before parsing. I would actually love to be able to have variants with +/- subcommands so the repl subcommand wouldn't show while in repl mode, and exit/quit would show... but I expect that would be hard to achieve in anything like a graceful way.

So if I understand, your commands can either be used as subcommands on the CLI or as part of the REPL?

You could do this by having the common subcommands in an enum and you can #[clap(flatten)] that enum into the CLI and into the REPL.

This example doesn't take advantage of the colored output included in the help text... using err.print() would provide that.

Yeah, I was being lazy. That should be fixed to get all of the best practices.

Using string comparison, rather than something like an enum for the subcommand is more likely to encounter typos. It also stops the use of an exhaustive match to provide compile-time feedback if a new command is added, but not implemented.

Thats the cost of using the builder API. We had considered finding a solution for it but the benefits didn't outweight the cost (#1104).

Ideally we'd have all examples in both builder and derive, we just haven't gotten to it yet. The builder ones are more universal since they are more explicit so people can do derives based on them.

. I could use the prompt in place of the application name, and include quit/exit when the prompt is used, and while also leaving out the repl subcommand. That's a big if, though, and it's not clear if that's the intended functionality.

no_binary_name just means we don't assume the first argument is a bin but is instead an argument

multicall treats the first argument as both the bin name and an argument.

Both assume the first argument is a path and will strip out to just the binary base name.

I am planning to update the documentation to recommend multicall for repl's and provide guidance on customizing it.

[andrewring]

Sounds great. I'll have to play with the flatten idea. Thanks for all the hard work you put into this excellent library!