-
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
Feature request: disallow option parameter values resembling option names #639
Comments
Thanks for raising this. Reproducing the issueI created a small test to reproduce the problem: @Test
public void testUnknownOptionInVariableArityValue() {
class App {
@Option(names = {"-x", "--xvalues"}, arity = "0..*")
List<String> x;
@Option(names = {"-y", "--yvalues"}, arity = "0..*")
List<String> y;
}
CommandLine cmd = new CommandLine(new App());
try {
cmd.parseArgs("-x", "0", "1", "-unknown", "-y", "A", "B");
fail("Expect exception");
} catch (UnmatchedArgumentException ex) {
assertEquals("Unknown option: -unknown", ex.getMessage());
}
} AnalysisThe above test fails because the This only happens when picocli is parsing values for a variadic option (an option with The problem is in Unknown Option HandlingI need to think about what the best way is to resolve this, in a way that is consistent with current behaviour for unknown options and other configuration options related to unknown options. Picocli's default behaviour, outside of variadic options, is to reject unknown options. Existing configuration options for unknown options are:
ResolutionSome ideas for dealing with this issue:
Adding a new parser option is probably the best solution. What I'm less sure about is what should be the default behaviour. Rejecting by default might break existing applications that rely on the current behaviour. On the other hand, it would be more consistent with behaviour in other contexts. I need to think about this a bit more. Feedback welcome. WorkaroundA workaround is to do validation in the application. One idea is to have an class App {
List<String> x;
List<String> y;
@Spec
CommandSpec spec;
@Option(names = {"-x", "--xvalues"}, arity = "0..*")
void setX(List<String> newValues) {
validate(newValues);
x = newValues;
}
@Option(names = {"-y", "--yvalues"}, arity = "0..*")
void setY(List<String> newValues) {
validate(newValues);
y = newValues;
}
void validate(List<String> newValues) {
for (String value : newValues) {
if (value.startsWith("-") || value.startsWith("--")) {
throw new UnmatchedArgumentException(spec.commandLine(), "ERROR: Unknown option: " + value);
}
}
}
} |
CORRECTION: this is not limited to variadic options (options with variable arity like Any option with a String option parameter can accept a value that "looks like" an option. @Test
public void testUnknownOptionAsOptionValue() {
class App {
@Option(names = {"-x", "--xvalue"})
String x;
@Option(names = {"-y", "--yvalues"}, arity = "1")
List<String> y;
}
App app = new App();
CommandLine cmd = new CommandLine(app);
cmd.parseArgs("-x", "-unknown");
assertEquals("-unknown", app.x);
cmd.parseArgs("-y", "-unknown");
assertEquals(Arrays.asList("-unknown"), app.y);
} So, perhaps a better name for our new parser option may be |
Thanks, For interest and reducing confusion, what do other CLIs do? Is leading |
For unix CLI utilities, the POSIX standard specifies that when For example:
In the above, The
In the above, |
I have started working on this. |
…disallow option parameters resembling options
Fixed in master. |
Summary: an option value with leading
--
(--junk
) is not trapped and is added to option values.This is not a complete program. (see
code at:
The class
AMISummaryTool
contains:The test module
gives:
The text was updated successfully, but these errors were encountered: