Abort parsing when encountering help option (was: MissingParameterException thrown when subcommand has required options and help option is defined)

[drkilikil]

Hi,
If I run the sample below with the command line: -h subcmd Picocli throws the MissingParameterException exception.
The required option must be provided to print help of the main command.
-h subcmd -o foo prints help in the same way as -h subcmd when the option is not required.
Is it possible to not check subcommands when a "help" option is specifed on the command line?
Cheers.

@Command(
    name = "app",
    mixinStandardHelpOptions = true,
    subcommands = [SubCommand::class])
class Application {
}

@Command(name = "subcmd", description = ["The description of the sub command."])
class SubCommand : Runnable {
    @Option(names = ["-o"], description = ["The option."], required = true)
    lateinit var opt: String

    override fun run() {
        println("running sub command with -o=$opt...")
    }
}

fun main(args: Array<String>) {
    val exitCode = CommandLine(Application()).execute(*args)
    exitProcess(exitCode)
}

[remkop]

Hi @drkilikil

Are you trying to get help for the (app) top-level command or for the subcmd subcommand?

The -h option is specified after the command for which to display the usage help message.

To get help for the app top-level command, users would run:

<cmd> -h

To get help for the subcommand, users would run:

<cmd> subcmd -h

The last example should not throw a MissingParameterException and should not require the user to specify the -o option. Is this not what you are seeing?

[drkilikil]

Display help for the top-level or sub commands is clear and not problematic.
I just wanted to point out that imho there is a case which throws exception and displays the wrong help message.
I expect to show help for the top-level command when running <cmd> -h whatever users would type after:

<cmd> -h -unknown-option => show help messsage for the top-level command
<cmd> -h unknown-subcommand => show help messsage for the top-level command

if '-o' is optional:
<cmd> -h subcmd => show help messsage for the top-level command

if '-o' is required:
<cmd> -h subcmd -o foo => show help messsage for the top-level command
<cmd> -h subcmd -unknown-option => throw exception and show help messsage for the subcommand
<cmd> -h subcmd => throw exception and show help messsage for the subcommand

The last two commands should show the help message for the top-level command.
It would be consistent to display the same help message regardless of the other arguments specified.
Hope to be clear with the explanation given, but it is a detail and not a real issue.

[remkop]

You make a good point. Thank you for the clarification.

To rephrase your point: shouldn't the picocli parser abort parsing further command line arguments as soon as it encounters the --help|-h option? Similarly for --version|-V.

I agree that this does seem to be the intuitive thing to do.

[drkilikil]

To rephrase your point: shouldn't the picocli parser abort parsing further command line arguments as soon as it encounters the --help|-h option? Similarly for --version|-V.

This is exactly what I mean.

And thanks for this great tool. A really good job!

[remkop]

Glad to hear you like picocli! 😊
Please star ⭐ picocli on GitHub when you get a chance! 😉

[remkop]

I finally got a chance to look at this.
I pushed a fix to master, so this will be included in the next release.
Thank you again for raising this!