-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default arity should be 1, not *, for array and collection options #192
Labels
Milestone
Comments
This was referenced Sep 28, 2017
This has been implemented. |
remkop
added a commit
that referenced
this issue
Oct 1, 2017
remkop
added a commit
that referenced
this issue
Oct 3, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently if an option for a list or array field doesn't have an explicit
arity
attribute, the default is to be greedy: consume as many arguments as possible until the next option or until the--
end-of-options delimiter is encountered.This causes a number of problems:
--
end-of-options delimiter on the command line)Example
To illustrate, consider the following application:
Current (incorrect)
Currently (as of v1.0.1) this input gives the following output:
This default behavior is counterintuitive for applications that also have positional parameters. It becomes impossible to see where the options stop and the positional parameters begin unless the user specifies the
--
end-of-options delimiter.Correct
Instead, we want the parser to behave like this:
That would be consistent with how most Unix tools work. Most Unix tools would expect the option to consume only one argument. The option can then be specified multiple times in order to collect multiple values. E.g.,
Solution
This ticket proposes to change the default behavior to consume only one argument for list/array options that don't have an explicit
arity
attribute defined.Users will be able get the current greedy behavior by explicitly specifying
arity="1..*"
.This will solve the above problems but may cause disruption for existing users/applications who rely on the current behaviour. I am not happy about that, but I believe this change is necessary to keep moving picocli forward. I hope that bumping the version number to 2.0 to signal an incompatible change will help reduce the disruption.
The text was updated successfully, but these errors were encountered: