Skip to content

Fix detection of the implicit help option - #1371

Open
czpilar wants to merge 1 commit into
spring-projects:mainfrom
czpilar:patches/1370-help-option-detection
Open

Fix detection of the implicit help option#1371
czpilar wants to merge 1 commit into
spring-projects:mainfrom
czpilar:patches/1370-help-option-detection

Conversation

@czpilar

@czpilar czpilar commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Resolves #1370

isHelp() now ignores options the command declares itself, so a declared -h is no longer hijacked as help. The dispatch condition is relaxed from options.size() == 1 to anyMatch, so help is honoured alongside other options - the two defects cannot be fixed separately, see the issue for why.

Case sensitivity

isHelp() also matched the long form case-insensitively, unlike every other option comparison in the codebase. This PR changes it to "help".equals(...), so --HELP is no longer treated as help. Repro and details in #1370.

The alternative - making the long form consistently case-insensitive - would imply -H is help, and -H is an established distinct flag elsewhere (curl -H, grep -H, ls -H), which is exactly the hijack this PR fixes. Nothing documents the uppercase spelling: the built-in help prints --help or -h for every command, and the reference docs mention only
--help / -h.

Note on the dispatch condition

commands/help.adoc already states that help short-circuits execution "regardless what other command-line options are typed", so relaxing options.size() == 1 to anyMatch brings the code in line with documented behaviour rather than changing it.

Signed-off-by: David Pilar <david@czpilar.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

--help detection ignores a command's own options

1 participant