Pretty exit for subcommand with required arg.

[jmbarbier]

Using clap derive for a cli like cli user <USER> <COMMAND>, for the following (derive) code

use clap::{Args, Parser, Subcommand};

#[derive(Parser)]
#[command(version, about, long_about = None)]
#[command(propagate_version = true)]
struct Cli {
    #[command(subcommand)]
    command: Commands,
}

#[derive(Subcommand)]
enum Commands {
    User(UserArgs),
}

#[derive(Args)]
struct UserArgs {
    /// User identifier
    user: String,
    #[clap(subcommand)]
    command: UserSubCommands,
}

#[derive(Subcommand)]
enum UserSubCommands {
    /// Display user
    Display,
    /// Delete user
    Delete,
}

fn main() {
    let _ = Cli::parse();
}

If the user does not provide the username, we have the "pretty exit" :

$ cliq user
Usage: cliq user <USER> <COMMAND>

Commands:
  display  Display user
  delete   Delete user
  help     Print this message or the help of the given subcommand(s)

Arguments:
  <USER>  User identifier

Options:
  -h, --help     Print help
  -V, --version  Print version

With the username and help subcommand, we also have the "pretty exit" :

$ cliq user toto help
Usage: cliq user <USER> <COMMAND>

Commands:
  display  Display user
  ...

But if the user is provided, but not the command, the not so pretty "error exit" is provided

$ cliq user toto

error: 'cliq user' requires a subcommand but one was not provided
  [subcommands: display, delete, help]

Usage: cliq user <USER> <COMMAND>

For more information, try '--help'.

Hence my question : **how can we display the "pretty exit" instead of "error exit" in this case ? (i tried arg_required_else_help, subcommand_required on every possible location, but no success...)

Thank you !!

[epage]

There used to be a setting SubcommandRequiredElseHelp which was removed in favor of separate arg_required_else_help (if any type of arg is present, no help is shown) and subcommand_required.

This was done for a couple of reasons

• These are mostly redundant and we are working to reduce redundancies in the API to improve build times, reduce binary size, and make the API more discoverable by not overwhelming users
• imo The error message, rather than help, is a better, more user friendly response. The help message doesn't say what the user did wrong and isn't giving directed feedback. Some CLIs do both, show the error and help but I feel like the error message is lost in all of the help output.

[jmbarbier]

Ok, so if i want to recreate this behavior, i have to quit the "derive" way of life and implement the condition on my own. Anyway, thanks for the answer !