From def3bf9bced4a387ef7fbc12ec0ec3d1b7659643 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20M=C3=BCller?= Date: Wed, 21 Feb 2024 08:08:47 -0800 Subject: [PATCH] Fix help text display for sub-commands The logic we added for displaying extensions in the program's help text turned out to be faulty when the user asked for the help to a sub-command. Evidently, the display of such a sub-command help text is covered by the same error kind, but it is wrong to simply display the program help text unconditionally. With this change we fix this state of affairs by re-triggering the program parsing on the custom crafted command object, which will ensure that the correct help text is printed on error. --- src/main.rs | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/main.rs b/src/main.rs index dd6a889..c5280cb 100644 --- a/src/main.rs +++ b/src/main.rs @@ -1872,7 +1872,17 @@ async fn run() -> Result<()> { .about(about as &'static str), ); } - let () = clap.print_help()?; + + // Note that this path may be invoked on paths that ultimately + // do *not* display the program help (but rather that of a + // subcommand). As such, just invoking `clap.print_help()` + // will *not* do the right thing. Instead, re-parse arguments + // here again. + // SANITY: We parsed the same program arguments above and + // err'd out. We assume we do the same thing here + // again, as nothing of relevance has changed. + let err = clap.try_get_matches_from(args_os()).unwrap_err(); + print!("{}", err); } return Ok(()) },