no_binary_name(true) not reflected in help output of subcommand

[RustyJoeM]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Rust Version

rustc 1.60.0 (7737e0b5c 2022-04-04)

Clap Version

3.1.12

Minimal reproducible code

CLAP is used inside of running app in "demon" mode using the rustyline crate.
(rustyline="9" for Cargo.toml)

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(no_binary_name(true))]
pub struct Args {
    #[clap(subcommand)]
    pub command: Command,
}

#[derive(clap::Subcommand, Debug)]
pub enum Command {
    Hello { address: std::net::IpAddr },
}

fn main() {
    let mut rl = rustyline::Editor::<()>::new();
    loop {
        match rl.readline(">> ") {
            Ok(line) => match Args::try_parse_from(line.split_whitespace()) {
                Ok(args) => {
                    dbg!(&args);
                }
                Err(err) => {
                    println!("{}", err.to_string().trim());
                }
            },
            Err(err) => {
                println!("{}", err);
                break;
            }
        }
    }
}

Steps to reproduce the bug with the above code

• run the above minimal program
• issue help hello command in running REPL

Actual Behaviour

When above app is executed, and help hello command is issued:

     Running `target\debug\repro.exe`
>> help hello
repro-hello
greeting

USAGE:
    repro hello <ADDRESS>

ARGS:
    <ADDRESS>

OPTIONS:
    -h, --help    Print help information
>>

Expected Behaviour

• there should be no "repro-hello" in heading of help output
• there should be no "repro" binary name in generated USAGE - line that shows how to runn the "hello" command

Additional Context

No response

Debug Output

No response

[epage]

This came out of the conversation in #3664

[RustyJoeM]

just a side note/small extension, this is also valid and behaving in same manner (possibly incorrect?) for an error reported on subcommand typo:

error: The subcommand 'hell' wasn't recognized

        Did you mean 'help' or 'hello'?

If you believe you received this message in error, try re-running with 'repro -- hell'

USAGE:
    repro <SUBCOMMAND>

For more information try help

The "if you believe..." line possibly does not apply to demon mode of CLAP -> when running without program name?
Plus USAGE section contains binary name, possibly generated by same/similar code that is done for original "help hello" case.

[epage]

I'm starting to wonder if we should leave no_binary_name to just change how we parse arguments but instead polish up #2861 for use for repls. We should also look to provide a repl example.

no_binary_name is just that and you could be handling arguments at the top-level while multicall more indicates that the very first argument should be a subcommand and we can better organize behavior around that.

[epage]

Starting an example for REPLs so we can more easily evaluate what might need to be done. See #3675

[epage]

Could you provide feedback on

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

[RustyJoeM]

Imho new REPL example is good & simple enough to follow quickly. It seems to give expected output on help subcommand.
(minus the issue metnioned by you in "stabilization" link above with unrecognized subcommand entered & empty <APPLET> help message...)

Small enhancement might be extra example variant for clap derive-oriented users.

I will try to switch my current codebase to multicall (thus doing a bit more testing in larger codebase) after resolving my currently completely unrelated -> Box<dyn GenericTrait> beginner problems. :)

From my point of view as "author" of issue, feel free to close/resolve as needed, thank you!

[epage]

(minus the issue metnioned by you in "stabilization" link above with unrecognized subcommand entered & empty <APPLET> help message...)

Could you post what your concerns are in that issue so we can continue the discussion there? Even if its exactly what I said, I'd like it coming from your use case in your words. I was considering stablizing it as-is :).

Small enhancement might be extra example variant for clap derive-oriented users.

Ideally, all of our examples are for both derive and builder but the minimum bar is builder because its more explicit so the builder users have the context they need while it should also be adaptable by derive users.

[RustyJoeM]

Hopefully this comment wont reopen the issue, if so, apologies and please re-close :)

Scratch/nevermind that comment of mine, it's just small divergence of my quick expectation and actual architecture of help segments.

What i meant was this output in REPL example:

$ fwfwef
error: The subcommand 'fwfwef' wasn't recognized

USAGE:
    <APPLET>

For more information try help

Here i sort of expected subcommands directly visible as part of USAGE, but following the actual instructions of last line output provides all the info needed:

$ help
APPLETS:
    help    Print this message or the help of the given subcommand(s)
    ping    Get a response
    quit    Quit the REPL

[epage]

Yes, there are multiple strategies for what to do on an error and that is something I plan to include in the doc comment for multicall is explaining the different strategies and how to accomplish them, including showing all the applets when the current one isn't understood.