[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly

["Aaron Gaudio (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092575#comment-15092575 ] 

Aaron Gaudio commented on CLI-221:
----------------------------------

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)