Note that the alternative would have been that no such subcommand exists.

$ cargo run-gfdklfgjdfjkgjkldg
error: no such command: `run-gfdklfgjdfjkgjkldg`

        View all installed commands with `cargo --list`
        Find a package to install `run-gfdklfgjdfjkgjkldg` with `cargo search cargo-run-gfdklfgjdfjkgjkldg`

The reason we gave the manifest command error, instead of no-such-subcommand error, is because of the slashes in the argument. We interpreted that as a path (seeing as those are illegal for subcommand names).

For myself, I'm having a hard time seeing how this kind of situation would be common enough for us to detect and report for. This requires a lack of spaces between the subcommand name and wherever a path-like may show up. Cases besides cargo run with -- and a path-like would be like check--manifest-path=foo/Cargo.toml seem rare.

People might have an alias test-runner and they somehow forgot the space in bewteen:

$ cargo test-runner./snapshots
error: running `test-runner./snapshots` requires `-Zscript`

The message is not ideal for new Rust users to identify what's going on, as it points to a nightly feature they don't know.

Maybe we could give the “no such subcommand” error still, with a bit richer message for -Zscript, so people don't know it can learn about its existence :)

$ cargo test-runner./snapshots
warning: no such subcommand: `test-runner./snapshots`

error the `cargo <single-file-package>` command is unstable, and only available on the nightly channel of Cargo, but this is the `beta` channel
See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
See https://github.com/rust-lang/cargo/issues/12207 for more information about the `cargo <single-file-package>` command.

diff --git a/src/bin/cargo/commands/run.rs b/src/bin/cargo/commands/run.rs
index 170c7ddf1a0..f8bdc8a0f10 100644
--- a/src/bin/cargo/commands/run.rs
    b/src/bin/cargo/commands/run.rs
@@ -97,8  97,15 @@ pub fn is_manifest_command(arg: &str) -> bool {
 }
 
 pub fn exec_manifest_command(config: &mut Config, cmd: &str, args: &[OsString]) -> CliResult {
-    if !config.cli_unstable().script {
-        return Err(anyhow::anyhow!("running `{cmd}` requires `-Zscript`").into());
     if let Err(e) = config.cli_unstable().fail_if_stable_command(
         config,
         "<single-file-package>",
         12207,
         "script",
         config.cli_unstable().script,
     ) {
         config.shell().warn(format_args!("no such subcommand: {cmd}\n"))?;
         return Err(e.into());
     }
 
     let manifest_path = Path::new(cmd);

Or maybe other ad-hoc message can help

I'm fine with providing some way to combine the messages pre-stabilization. My comment was more looking forward to when we do stabilize. How should the error look in that case? I feel like we should start there and work backwards or else we'll just mask this until stabilization and then regress.

@epage What if we check to make sure the path actually exists first? Then we could say something like we interpreted the command as an attempt to run a script, but the file doesn't exist.

It's hard to guess the intent of a user, and “no such subcommand” is a good choice in the meantime when waiting for feedback from others.

Some ideas:

• Split the invalid subcommand name by known subcommands, and give a bold guess like did you mean "cargo test-runner ./snapshots"?
• Walk the current directory, and find if there is a file with a similar name of "test-runner./snapshots".