[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008544#comment-18008544
]
Joerg Budischewski commented on CLI-221:
----------------------------------------
Strictly speaking, the described behaviour in CLI-221 is not a bug
as it is needed to fulfill the documented behaviour described in
https://issues.apache.org/jira/browse/CLI-325
around interpreting java property like arguments.
However, when you want to parse list values instead of java properties,
the behaviour is bad as the user need to terminate a list argument with
double dash --, which is counterintuitive.
Also changing the option's order changes the behaviour.
The suggested solution in PR https://github.com/apache/commons-cli/pull/382
adds the new
Option.Builder.listValueSeparator() methods, which must be used instead
of Option.Builder.valueSeparator() to achieve the behaviour desired
in this issues' description, see javadoc for usage.
It is only added in the DefaultParser() and not fixed for the
other deprecated parser implementations.
The user can then use the option in any order, e.g.
- cmd1 -o1 blue,green,yellow -f otheroption a1
- cmd1 -f otheroption -o1 blue,green,yellow a1
- cmd1 a1 -f otheroption -o1 blue,green,yellow
> cli's with last option as list type values and have argument are not parsed
> correctly
> -------------------------------------------------------------------------------------
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
> Affects Versions: 1.2
> Reporter: Gagan Jain
> Priority: Major
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 <comma separated values> a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
