[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012383#comment-18012383
]
Joerg Budischewski commented on CLI-221:
----------------------------------------
[~claude]: Thank you for your time to discuss it.
As I see a little chance of misunderstanding each other here, I want to
distinguish what is already there in 1.10.0 and what is my proposed PR
Shortly summarized, in 1.10.0 without my PR, the valueSeparator defaults to '='
and is used to split possible multiple values and was probably initially
designed to parse this property style like that:
-D a=1 c=2
to be able to later invoke cmdLine.getOptionProperties(option) and then get the
properties a and c with values 1 and 2 (see cli-325).
However, when you don't use later cmdLine.getOptionProperties(), you could also
use this same valueSeparator (ideally than redefining the = to a ',' to make it
better readable) to parse something like that:
-D 1,2,3
, however to to support the above "property" syntax (which we don't know
whether it will be used at parsing time) leads to the strange interpretations
-D 1,2,3 4,5
is now added to the list of option D with 5 values 1 2 3 4 5, and this is very
unexpected for the API users, as they expect only 3 values 1 2 3 to be assigedn
to D and 4,5 to be the next arg.
My PR now proposes the new listValueSeparator() (defaulting to ',' but can be
overwritten), which basically means, only use the next argument for
interpreting the list of values, do not expect addtional following args to
belong to that option, so that
-D 1,2,3 4,5
would then have D with the values 1 2 3 and 4,5 would be the first non-option
argument. The listValueSeparator is internally stored as the same
valueSeparator as above (to reuse most of the functionality and reduce risk of
breaking something) with an additional flag that we are in this special case.
Do you agree that we can solve it this way ? I am then happy to look into the
edge cases and document them properly both for valueSeparator and
listValueSeparator style. I would also add, that when using
listValueSeparator(), the cmdLine.getOptionProperties() should not be used.
> 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)
