[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012834#comment-18012834
]
Claude Warren commented on CLI-221:
-----------------------------------
I was not thinking of reimplementing the parser. Rather, taking a different
approach to the problem.
Basically the OS provides a list of tokens.
The parser assums (with a few exceptions) that anything starting with a dash is
an option.
If the option accepts arguments it assumes (with a few exceptions) that any
following tokens that do not start with a dash are arguments to the option.
At this point we have the option and logically the option has zero or more
string arguments.
The converter pattern is fairly recent but it allows conversion from string to
something else.
So, for example the int data type applies a standard integer conversion to that
getParsedOption returns an int.
My thought was, the user specifies a conversion and we just apply it to the
list of objects
Now determining how items are parsed is down to how does the OS parse the input
string into tokens.
so "-D 1,2,3 4,5" is parsed by the OS as "-D", "1,2,3", "4,5"
if you apply a ListConverter with a separator of "," then you get
Option {
key: -D,
values: [["1","2","3"], ["4", "5"]]
}
So 2 arrays of strings.
Composing a ListConverter with an IntegerConverter would yield
Option {
key: -D,
values: [[1,2,3], [4, 5]]
}
So 2 arrays of integers.
The above 2 examples assume that -D option allows multiple arguments.
If it only accepts 1 argument then "4,5" would be left as an unused command
line argument.
if it accepts multiple arguments and the user wants to force "4,5" to be an
unused command line argument then the original arguments should be "-D 1,2,3 --
4,5"
This direction means that your change becomes a ListConverter where you can
specify what the separator character is.
We will have to do some work to allow composition with other Converters.
The ListConverter could also be a subclass of CollectionConverter so that we
can have Set as well as List.
A MapConverter or PropertyConverter would eventually replace the Property
methods that would be a later change.
> 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)
