[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012815#comment-18012815
]
Joerg Budischewski commented on CLI-221:
----------------------------------------
ok, I am not the guy to be able to reimplement the parser, so I would then
close the PR so that someone else might pick it up.
But I want to add my 2cts here.
So first, do you suggest an incompatible change ? For the rest of this comment,
I assume the API is kept compatible and your suggestion is an addition.
I think, no matter how the user later accesses the values
(cmdLine.getOptionProperties() , option.getValue() or your new proposed
cmdLine.getParsedOptionValues()), it must be clear from option definition
whether
-D 1,2,3 4,5
is interpreted as
1) arg1=List[1,2,3] and arg2=4,5
or
2) arg1=List[1,2,3,4,5]
. At the moment, the current Option API does not allow to define the first
interpretation when using a valueSeparator.
Do you suggest, that this problems remains in the "old" access API and the new
access API then allows both interpretations ?
But then, the new and old api can't even agree on the number of arguments (and
even flavors of the new API would disagree on number of args), this sounds very
confusing to me.
I think, users want a simple way to say, that a certain argument is to be
interpreted as a list of values with this ticket, that's it, and for that, you
need to add something like the listValueSeparator() proposed in this PR.
> 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)
