[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092575#comment-15092575
]
Aaron Gaudio edited comment on CLI-221 at 1/11/16 8:06 PM:
-----------------------------------------------------------
I concur with this bug report; in fact I came here to file a bug for the same
thing before I found this one (I can personally confirm this still happens in
version 1.3, and having looked at the source code in 1.4 beta, I'm pretty sure
it still happens there).
I think Thomas' response above is too reliant on the documentation and not
considering the most likely intent of a programmer using this option. I have
never seen a program in which something like "\--option value1,value2 value3"
was interpreted as 3 values (value1, value2, and value3) for the option. It
just doesn't make sense. You'll be hard-pressed to find someone who doesn't
interpret the above args as two values (value1 and value2) for the option and
an additional argument (value3).
My suggestion for a fix is that if an option has a custom separator character
that isn't a space, and you're parsing a separate token from the command line
(e.g. "\--option value1,value2" versus "\--option=value1", once you've parsed
the separate token ("value1,value2"), unset the active option so that any
subsequent tokens are not considered values for that option.
Additionally, it would be nice if the separator between the option name and the
value(s) were distinct from the value separator, so that you can do something
like this: "\--option=value1,value2". I suspect some of the problems like this
bug report arise from conflating the option/value separator from values
separators (e.g. you want to support both "\--option=value1" and "\--option
value1" when someone sets the separator to '='; but per this report, nobody is
really looking to support both "\--option value1,value2,value3" *and*
"\--option value1 value2 value3", much less a mix of them; also desire for
"\--option=value1=value2=value3" is not very likely to be something somebody
wants for multiple values, but "\--option=value1,value2,value3" is very likely).
was (Author: matunos):
I concur with this bug report; in fact I came here to file a bug for the same
thing before I found this one (I can personally confirm this still happens in
version 1.3, and having looked at the source code in 1.4 beta, I'm pretty sure
it still happens there).
I think Thomas' response above is too reliant on the documentation and not
considering the most likely intent of a programmer using this option. I have
never seen a program in which something like "--option value1,value2 value3"
was interpreted as 3 values (value1, value2, and value3) for the option. It
just doesn't make sense. You'll be hard-pressed to find someone who doesn't
interpret the above args as two values (value1 and value2) for the option and
an additional argument (value3).
My suggestion for a fix is that if an option has a custom separator character
that isn't a space, and you're parsing a separate token from the command line
(e.g. "--option value1,value2" versus "--option=value1", once you've parsed the
separate token ("value1,value2"), unset the active option so that any
subsequent tokens are not considered values for that option.
Additionally, it would be nice if the separator between the option name and the
value(s) were distinct from the value separator, so that you can do something
like this: "--option=value1,value2". I suspect some of the problems like this
bug report arise from conflating the option/value separator from values
separators (e.g. you want to support both "--option=value1" and "--option
value1" when someone sets the separator to '='; but per this report, nobody is
really looking to support both "--option value1,value2,value3" *and* "--option
value1 value2 value3", much less a mix of them; also desire for
"--option=value1=value2=value3" is not very likely to be something somebody
wants for multiple values, but "--option=value1,value2,value3" is very likely).
> 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
>
> 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
(v6.3.4#6332)
