commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Gaudio (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
Date Mon, 11 Jan 2016 20:02:39 GMT

    [ 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)

Mime
View raw message