How do I know that --help or --version will be invoked from ParseResult?

[ptr727]

After calling Parse() to get ParseResults, I want to test if --help or --version will be invoked, and if so, I want to bypass expensive and pointless app startup and just immediately exit calling Invoke().

I have not found a way looking at e.g. ParseResult.CommandResult.Command.Name to see if help or version will be invoked, as e.g. Name is just the app name.

How can I determine if help or version default commands will be invoked parsing?

[baronfel]

There's not a one-shot way to do so, but if you investigate ParseResult.CommandResult.Children, if help or version were called one of the children will be an OptionResult, whose OptionResult.Option.Name will be --help, --version, etc.

[ptr727]

Ok thx, this seems a bit brittle, but works for --version and --help and command --help.

        // Exit immediately in case of parsing error or --help or --version
        if (
            commandLineParser.Result.Errors.Count > 0
            || commandLineParser.Result.CommandResult.Children.Any(symbolResult =>
                symbolResult is OptionResult optionResult
                && (
                    optionResult.Option.Name.Equals("--help", StringComparison.OrdinalIgnoreCase)
                    || optionResult.Option.Name.Equals(
                        "--version",
                        StringComparison.OrdinalIgnoreCase
                    )
                )
            )
        )
        {
            return commandLineParser.Result.Invoke();
        }

[baronfel]

I'm curious though - in S.CL, help and version are things that can be invoked - literally when they are parsed they set the Action of the CommandResult to call their implementations instead of that of the detected command. What is driving you to want to sidestep this?

[ptr727]

As I mentioned, it is pointless to fire up the entire app, start loggers, start timers, do maintenance, to then just have the CLI print text and exit without actually invoking a command.
So if I know the CLI parser is going to just print some info, e.g. help, version, command version, then just exit with invoke and bypass startup.
Sure, it is not the end of the world to do normal startup, but if an easy and deterministic way to check why not.

[jonsequitur]

This is a question, not a suggestion, but I'm curious about why those setup steps aren't in the command handler.

[ptr727]

Environment setup is based on global root options, i.e. parse root, get global options, configure environment, then launch command, and command handler expects environment to already be configured.

Now you are right I could have designed it that every handler setups the environment before running, but process startup is in effect a separate step, e.g. for options like wait for debugger to attach running before the command handlers are invoked, and starting with minimal logging to log early startup, and then reading logging config and extending logging.

Asking the CLI handler if there was a parsing error, or if it will execute something that is not one of my handlers, seemed like a good early exit optimization.