Jan Høydahl created SOLR-18649:
----------------------------------
Summary: solr --help exits 1; a help request should succeed
Key: SOLR-18649
URL: https://issues.apache.org/jira/browse/SOLR-18649
Project: Solr
Issue Type: Bug
Components: cli
Reporter: Jan Høydahl
*Found by CATS*, the cross-platform CLI test framework proposed in SOLR-18642 —
see [PR #5323|https://github.com/apache/solr/pull/5323]. A test there asserts
the correct behaviour and is marked {{@AwaitsFix}} against this issue so the
suite stays green. A fix can land before CATS is merged or after; if it lands
first, please also drop the {{@AwaitsFix}} annotation from that test on that PR.
h3. A plain help request returns failure
Measured on a built distribution, bare {{solr \-\-help}}:
|| || bash || cmd.exe ||
| commons-cli (today's default) | 1 | 1 |
| picocli | 1 | *0* |
Only one of the four combinations is right. {{\-\-help}} is a requested action
that succeeded: the help was printed and nothing went wrong. A caller testing
the status, a Makefile, a CI step or a packaging smoke test sees a failure.
Per-subcommand help is already correct and is not affected: {{solr start
\-\-help}}, {{solr zk \-\-help}} and {{solr status \-\-help}} all exit 0 on
both shells and both implementations.
Note that SOLR-18561, flipping the default to picocli, does not fix this on its
own: {{bin/solr}} would still send an empty argument, so bash would stay at 1.
h3. Three contributors, all of which have to change
*1. {{bin/solr}} never asks for help.* Lines 588-594 send an empty argument and
inherit the tool's status:
{code}
if [ $# -eq 1 ]; then
case $1 in
--help|-h)
run_tool ""
exit
;;
esac
fi
{code}
So bash lands on the "no command given" path rather than a help path, under
either implementation.
*2. The commons-cli path treats a help request as a missing command.*
{{SolrCLI.parseWithCommonsCli}} lines 229-236:
{code:java}
final boolean hasNoCommand = args == null || args.length == 0 || args[0] ==
null || args[0].trim().isEmpty();
final boolean isHelpCommand = !hasNoCommand && Arrays.asList("-h",
"--help").contains(args[0]);
if (hasNoCommand || isHelpCommand) {
printHelp();
runtime.exit(1);
}
{code}
*3. The picocli no-subcommand path returns 1*, {{SolrCLI.call()}} lines
126-129. That is right for a bare {{solr}}, but it is where the script's empty
argument ends up after {{stripEmptyLeadingArg}} (lines 159-164) drops it — a
helper whose own javadoc describes it as working around the script's
empty-argument convention.
{{bin/solr.cmd}} needs no change: it passes {{\-\-help}} straight to the
generic dispatch at lines 266-274, which is why Windows with picocli is the one
combination that behaves.
h3. Suggested fix
Send a real help request from {{bin/solr:588-594}} and return success
explicitly — {{run_tool \-\-help}} followed by {{exit 0}} — matching what the
per-command path at 835-842 already does, and what {{solr.cmd}} does.
In {{SolrCLI.parseWithCommonsCli}}, split the two conditions, so
{{isHelpCommand}} exits 0 while {{hasNoCommand}} keeps exiting 1.
{{SolrCLI.call()}} can stay as it is: once the script stops sending an empty
argument it is reached only by a genuinely bare {{solr}}, where non-zero is
correct, and {{stripEmptyLeadingArg}} with its test then becomes dead code.
Expected afterwards: {{solr \-\-help}} exits 0 in all four combinations, a bare
{{solr}} still exits 1, and subcommand help is unchanged.
🤖 AI Assisted
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
