-
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
option is treated as option-parameter (was: option is treated as option-parameter in Arguments Groups) #1055
Comments
@waacc-gh Thank you for raising this! |
This behaviour is not limited to Argument Groups but can actually happen with any option that accepts a parameter. For example: @Command
public class QuickTest {
@Option(names = "-a") String a;
@Option(names = "-b") String b;
public static void main(String[] args) {
QuickTest quickTest = new QuickTest();
// value matches existing option
new CommandLine(quickTest).parseArgs("-a", "-b");
System.out.printf("-a=%s, -b=%s%n", quickTest.a, quickTest.b);
// value "resembles" an option
new CommandLine(quickTest).parseArgs("-a", "-c");
System.out.printf("-a=%s, -b=%s%n", quickTest.a, quickTest.b);
}
} This prints:
I will add this to the roadmap for the next release. There is an outstanding request to improve a similar situation where values "resembling options" are accepted as option parameters or as positional parameters. (Edit) I will probably introduce two separate parser switches to allow/disallow:
This will likely need to be enabled explicitly for backwards compatibility (the default behaviour will likely remain the current behaviour). Thoughts? |
The reason why I raised this issue is, I'm confused. The following examples behave different. Is this intended? (Yes I know, my example above is a little bit different. But I think it's more or less the same problem.)
|
Yes, you are right, the main problem of this issue is, to guess the intention of the user: is a command line argument starting with I'm not sure if additional parser switch(s) really solve this issue. Always treating an argument starting with A solution might be, to enforce using an (e.g.) Next idea: If an option is defined having an option-parameter, then the argument behind the option is always treated as its option-parameter. Putting ambiguous parameters between Maybe escaping the Sorry, till now, I do not have a simple and catchy solution. :-( |
I believe the best way forward it to provide parser options to disallow values that are actual options or are similar to options. When applications need to allow such values they can configure the picocli parser accordingly. I don't think that a general solution exists for this. Any further validation is the responsibility of the application. |
I also do not think that there is a general solution for every use case. And I've learned, it doesn't matter how many use case are considered, there is always another on. But in my opinion, the parse should act the same way in similar case and not different (like in the two example above). Escaping the |
You raised a good point that picocli's behaviour is currently different for single-value options and multi-value options: It is better if picocli would be consistent, so I am thinking now to by default also reject the first case, so that single-value options will also reject values that exactly match an existing option. That leaves two problems:
Thoughts? |
I started to work on this. |
Fixed in master. This will be included in the upcoming 4.4 release. |
see: #1054
called with:
-f pattern -w text
--> accepted --> ok-f -f -w text
--> accepted --> wrong:findPattern = "-f"
, means, the second-f
is treated as an option-parameter for the first-f
-f pattern -w -d
--> wrong:replacement = "-d"
, means-d
is treated as an option-parameter for-w
The text was updated successfully, but these errors were encountered: