> [With official release 1.2]
>
> I'd like to call a commmand "cmd" as follows:
> $ cmd --foo a --foo b --foo c cmdArg1 cmdArg2
>
> There can be any number of arguments to the option "--foo". When I try,
> the parser ("GnuParser") considers the "cmdArg1" and "cmdArg2" arguments as
> arguments to the "--foo" option.
> This is so even with the "stopAtNonOption" flag set to true.
>
> When I try
> $ cmd --foo 'a b c' cmdArg1 cmdArg2
> I don't get 3 separate option arguments "a", "b", "c", but a single string
> "a b c".
Also, is it standard practice to allow the syntax
$ cmd --foo a b c
for an option that can take multiple arguments?
[IIRC, "getopt_long" in C only allows *one* argument.] I think that the
above syntax makes parsing more difficult and leads to the problem which
I stumbled upon.
Could it be possible to solve this problem by adding a "post-processing"
of single-arg options that would further split the argument according to a
user-defined separator so that
$ cmd --foo 'a b c' cmdArg1 cmdArg2
would effectively end up like if it were a multiple-args option?
I.e. something that could be used as
---CUT---
final Option fooOpt = OptionBuilder.withArgName("Any of 'a' or 'b' or 'c'")
.isRequired()
.hasArg()
.splitWith("\\s+") // <--- New feature.
.create("foo");
---CUT---
So that when calling:
---CUT---
final String[] foo = line.getOptionValues("foo");
---CUT---
one would indeed get 3 separate arguments even if they were passed as a
single string "a b c" (or 'a b c') on the command-line.
What do you think?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
