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

["Simon Zee (JIRA)" <ji...@apache.org>]

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

Simon Zee edited comment on CLI-221 at 2/20/17 9:38 AM:
--------------------------------------------------------

Purely coming here to agree with others that the current behaviour is extremely unintuitive, and I can testify I personally have wasted hours puzzling over why changing the order of options seemed to break my code.

Consider that simply reordering the options completely changes the parsing:

ie:

  program -foo 1 -bar 1,2 fubar

parses differently to 

  program -bar 1,2 -foo 1 fubar

Nobody will expect that.

Here is a diff that resolves this issue for me:

{code}
Index: src/main/java/org/apache/commons/cli/Parser.java
===================================================================
--- src/main/java/org/apache/commons/cli/Parser.java    (revision 1783729)
+++ src/main/java/org/apache/commons/cli/Parser.java    (working copy)
@@ -340,7 +340,7 @@
             String str = iter.next();
             
             // found an Option, not an argument
-            if (getOptions().hasOption(str) && str.startsWith("-"))
+            if (getOptions().hasOption(str) && str.startsWith("-") || "--".equals(str))
             {
                 iter.previous();
                 break;
{code}


was (Author: simonzee):
Purely coming here to agree with others that the current behaviour is extremely unintuitive, and I can testify I personally have wasted hours puzzling over why changing the order of options seemed to break my code.

Consider that simply reordering the options completely changes the parsing:

ie:

  program -foo 1 -bar 1,2 fubar

parses differently to 

  program -bar 1,2 -foo 1 fubar

Nobody will expect that.

Here is a diff that resolves this issue for me:

Index: src/main/java/org/apache/commons/cli/Parser.java
===================================================================
--- src/main/java/org/apache/commons/cli/Parser.java    (revision 1783729)
+++ src/main/java/org/apache/commons/cli/Parser.java    (working copy)
@@ -340,7 +340,7 @@
             String str = iter.next();
             
             // found an Option, not an argument
-            if (getOptions().hasOption(str) && str.startsWith("-"))
+            if (getOptions().hasOption(str) && str.startsWith("-") || "--".equals(str))
             {
                 iter.previous();
                 break;


> 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.15#6346)