← Back to issue list

Always report error messages for incorrect usage

View original Github issue

Metadata

Project
craft-cli
Number
#262
Type
issue
State
open
Author
mattculler
Labels
—
Created
Updated
Closed
—

Current evaluation

CLI prints full help text instead of an error when invoked with no command; partially addressed by #422 which errors when a default command is disallowed, but the no-default-command case still dumps help text. Unlabelled, no maintainer response.

Suggested action: needs triage

Reason: The issue is unlabelled with no maintainer acknowledgement (only a Jira-sync bot comment). The core complaint is still valid: when no default command is configured, pre_parse_args() still raises ArgumentParsingError with full help text (dispatcher.py: 'help_text = self._get_general_help(detailed=False); raise ArgumentParsingError(help_text)'). PR #422 added a proper 'Missing a command' error but only for the allow_default_command=False path, leaving the no-default-command case unchanged. A maintainer needs to decide whether to change the remaining case.

Impact: 40 Quick Win: 28.0 Staleness: 72 Complexity: 30 Confidence: 75 Support Request: 5

Issue body

### What needs to get done Most CLI usage errors output exactly what I would expect - a basic usage line, suggestion to consult `-h`, and an error message: ``` $ corncraft foo Usage: corncraft [options] command [args]... Try 'corncraft -h' for help. Error: no such command 'foo' $ corncraft pack --foo Usage: corncraft [options] command [args]... Try 'corncraft pack -h' for help. Error: unrecognized arguments: --foo ``` But passing no command at all will instead output the help text, with no explanation. (It does return nonzero.) The "no command specified" case should get its own message. In my view, even a generic error message would be better than the help text, which is annoying - I would argue that we should also change the case where help output is displayed in response to a generic error. ### Why it needs to get done This will likely be confusing for new users.

Evaluation history

Date Model Scores Action Summary
qwen/qwen3.8-27b
Impact: 40
Quick Win: 28.0
Staleness: 72
Complexity: 30
Confidence: 75
Support Request: 5
needs triage CLI prints full help text instead of an error when invoked with no command; partially addressed by #422 which errors when a default command is disallowed, but the no-default-command case still dumps help text. Unlabelled, no maintainer response.
qwen/qwen3.6-35b-a3b
Staleness: 90
Complexity: 15
Confidence: 85
Support Request: 10
close stale CLI displays help text instead of an error when run without a command. Issue lacks labels, assignee, and maintainer engagement, remaining inactive for over 16 months.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 15
Confidence: 80
Support Request: 0
needs triage CLI displays help text instead of an error when invoked without a command. The issue remains unlabelled and unassessed by maintainers after over two years.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 20
Confidence: 80
Support Request: 0
needs triage CLI shows help text instead of an error when no command is provided. Requires a dedicated error message for missing commands. Open, synced to Jira CRAFT-3119, awaiting implementation.

Update history

No update history recorded yet.

Related work

  • Related To: craft-cli/craft-cli#422 (confidence 80%)

    PR #422 'feat: error on default command' added a 'Missing a command' ArgumentParsingError for the allow_default_command=False path, partially addressing this issue but not the no-default-command case.

Related issues

No related issues found above the similarity threshold.