[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012492#comment-18012492
]
Claude Warren commented on CLI-221:
-----------------------------------
I have implemented this differently in the new work in the RAT tool.
The option has a converter option, that will take a string and convert it to
something else. Typically used to parse integers and the like. However I
constructed a list converter that took strings like "a,b,c" and returned
List["a", "b". "c"]
Perhaps we can refactor some of the parsing strategy to use converters.
doing so makes it some of the work much easier. In this case the option
argument frame only needs to determine when the options have stopped and let
the application of the converter change the strings.
h2. Examples
h3. -D 1,2,3 4,5
becomes:
* Option frame reference: {Option D}
* Option argument frame reference \{Option D values=["1,2,3", "4,5"]}
* After applying a list converter by calling getParsedOptionValues("D") return
List[ List["1", "2", "3"], List["4", "5"] ]]
if the list converter had an option to flatten then it could return List["1",
"2", "3", "4", "5"]
h3. -D a=1 c=2
becomes
* Option frame reference: {Option D}
* Option argument frame reference \{Option D values=["a=1", "c=2"]}
* After applying a list converter by calling getOptionProperties("D") return
Properties\{ "a" -> "1", "b" -> "2"}
h2. Notes
* By restricting the parsing to initially breaking the options into lists of
String we can remove the complexity of what the user wants from the parse
outside of the tokenization of the argument to options.
* By applying converters we can return almost any type from the command line
option.
* By changing the converters simple Function instances, or by adding
"andThen()" method to the Converters, we can allow chaining of converters to do
things like, split "1,2,3" into List["1", "2","3"] and then apply Integer.parse
to create List[1, 2, 3].
* By replacing the implementation of getOptionProperties() with an additional
nesting of a converter we can simplify make it play nicely with other
converters.
* By switching to converters all the "option value separator" questions are
pushed out to the converter implementation which allows the user more control
over how the options arguments are parsed.
> 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)
