[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012325#comment-18012325
]
Claude Warren commented on CLI-221:
-----------------------------------
I am just coming back to this after a long time of being away so forgive me if
I miss something or misinterpret something. I think it might help to spell out
what the parsing rules we want around multiple options. What I think I am
reading is that:
# Options start with a dash or two dashes for long option values keys. (- or
--)
# A character is used to separate options. By default a space. ( )
# A character is used to separate multiple values for an option. By default a
comma (,) called Option.listValueSeparator
# A character is used to separate key/value pairs within a value. By default
an equal sign (=) called Option.valueSeparator
This set of rules solves the negative number issue as noted in CLI-306 because
the option values are separated by a comma.
We should probably think about parsing in terms of frames of reference.
Keep in mind that the option will contain the list of values at the end of
parsing.
h2. Command line frame of reference
We take the array of args passed on the OS command line and do the following:
* If there are no args left exit
* Check if the arg is a dash or double dash by without any characters
following. If so exit.
* Check if the arg has a dash with characters following. If so enter the
option frame of reference passing the arg and the iterator containing the rest
of the command line args.
* got to the start of this list.
h2. Option frame of reference
The option processing is a follows:
* if the option contains an equals sign (=) enter the option argument passing
the iterator containing the rest of the command line args.
** verify option is defined, if not exit.
** add value to option.
* else
** verify option is defined, if not exit.
* if option accepts arguments enter the option argument passing the iterator
containing the rest of the command line args.
* exit frame
h2. Option argument frame of reference
* if there are no mor tokens in the iterator, exit frame.
* get the next token from the iterator.
* If the token begins with a dash not followed by a number or double dash exit
frame. (See CLI-306)
* If the token contains the listValueSeparator split the token into multiple
values and add them to the option.
* got to start of this list.
The issues seem to arise when the Option argument frame can not determine when
the arguments to the option have been processed.
What happens if the listValueSeparator is a comma (,) and the tokens following
the option are ["one," "two"] the use of the listValueSeparator indicates
that the values for the option should be ["one" "two"] but it could also be
["one" ""] with "two" being seen as the end of the tokens.
There are a number of weird cases for end of option argument and I think we
should document them.
# a dash followed by a series of decimal digits and a Locale specific decimal
separator is a valid option argument and not a new option flag. (this poses
problems for the listValueSeparator as a comma or decimal depending on Locale).
# A listValueSeparator at the end of token.
# An equals sign at the end of an option name.
# An equals sign at the end of a token.
# An equals sign at the start of a token.
> 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)
