Better output information when requesting help for a command with bad arguments for that command
Metadata
Current evaluation
Command help still rejects extra command arguments; help close --bad-args should select close and render its help instead of reporting too many parameters.
Suggested action: keep open
Reason: The request remains unimplemented: dispatcher.py still raises whenever filtered help parameters are not exactly one command, and test_helprequested_too_many_parameters explicitly asserts the current error. The maintainer-authored report provides an exact input and expected output, while charmcraft#319 confirms the same downstream usability gap.
Evaluated by: mr-cal-bot
Impact:
38
Quick Win:
26
Complexity:
25
Confidence:
97
Actionability:
92
Issue body
It's typical the following situation: Try to run a command with bad args...
```
myapp somecommand --bad-args
```
...and then, when failed, ask for help on that:
```
myapp help somecommand --bad-args
```
Currently it fails because `--bad-args` is not really a valid argument for the help command. Real life example:
```
$ charmcraft help close --bad-args
Usage: charmcraft [options] command [args]...
Try 'charmcraft -h' for help.
Error: Too many parameters when requesting help; pass a command, '--all', or leave it empty
```
It should detect that the first given parameter is actually a command name, and it should provide help for that command, no matter the invalid posterior options. Expected:
```
$ charmcraft help close --bad-args
Usage:
charmcraft close [options] <name> <channel>
Summary:
...
```
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
38
Quick Win:
26
Complexity:
25
Confidence:
97
Actionability:
92
|
keep open | Command help still rejects extra command arguments; help close --bad-args should select close and render its help instead of reporting too many parameters. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
17
Complexity:
20
Confidence:
70
Actionability:
70
|
needs triage | Enhancement request to make 'help command --bad-args' show help for the command instead of failing with 'Too many parameters' error | |
| qwen/qwen3.8-27b |
Impact:
25
Quick Win:
15
Staleness:
55
Complexity:
40
Confidence:
85
Support Request:
5
|
needs triage | craft-cli help command errors with 'Too many parameters' when given a valid command name plus an invalid option (e.g. `charmcraft help close --bad-args`); it should show help for the named command. Still unfixed in current code; no maintainer triage, only a Jira-sync bot comment. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
15
Confidence:
80
Support Request:
5
|
close stale | The help command fails when passed invalid arguments intended for the target subcommand. It should ignore trailing invalid flags and display help for the specified command. Currently untriaged and inactive for over four years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
92
Complexity:
20
Confidence:
85
Support Request:
5
|
needs triage | Request to improve CLI help output by ignoring invalid trailing arguments when requesting help for a specific command. Currently fails with a parameter error. Untriaged and inactive for over a year. |
Update history
No update history recorded yet.
Related work
-
Related To:
charmcraft#319
(confidence 98%)
Reports the same command-help failure and was moved to this open craft-cli implementation issue.
Related issues
No related issues found above the similarity threshold.