[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012862#comment-18012862
]
Joerg Budischewski commented on CLI-221:
----------------------------------------
[~claude]
At the moment, converters are only used AFTER parsing. Do you suggest to keep
it that way ?
If yes, how shall e.g. CommandLine.getArgs() be implemented, when the option
converters decide, whether an additional arg is an argument or belongs to the
predecessor arg ?
I think that can't work with the current API without breaking the contract.
Beside that, the current API has the semantic
hasArg() (or alternatively numberOfArgs(1)) -> exactly one list value ( so -D
1,2 would be invalid, as it has got more than one value though it is passed in
1 arg).
numberOfArgs(n) with n > 1) --> must have exactly that number of values (no
matter if ',' or ' ' separated, so -D 1 2 and -D 1,2 would be valid for n = 2).
hasArgs() --> arbitrary number of arguments, must always be terminated with --
So in your suggestion, when hasArgs() is used, the end user is still forced to
use the -- to end argument parsing and that is exactly what the API's users
want to avoid as this is a very ugly/uncommon syntax they need to explain to
their end users.
While your suggestion (introducing introduce ListConverer, CollectionConverter,
SetConverter) might give a nicer way of working with the API in general (though
using the converters is imho not very intuitive for the casual user), I don't
see, how it improves what is addressed in this issue. It feels more like a new
separate Jira issue would be better, to specify, what exactly should be added.
> 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)
