how to separate list option values from unparsed args

[Arnd]

hi there,

i have just started with jewelcli after evaluating other frameworks for i it is the closest to
what i expect from such a framework compared to others.
so first: congratulations :-)

i have one problem using it regarding to list option values:

i have the following interface:

public interface DefaultConfiguration {

  @Option(defaultValue="3")
  int getMyOption();

  @Option(defaultValue=["3","4","5"])
  List<Integer> getMyList();

  @Unparsed(name="FILE", defaultValue=[])
  List<File> getFiles();
 
}

if i parse arguments like:

--myList="2 3 4 5" --myOption=5 file1 file2 file3

everything works as expected, but if i parse

--myOption=5 --myList="2 3 4 5" file1 file2 file3

i get an error:

cause Invalid value (Unsupported number format: For input string: "file1"): [--myList value...]
Invalid value (Unsupported number format: For input string: "file2"): [--myList value...]
Invalid value (Unsupported number format: For input string: "file3"): [--myList value...]

what i don't understand is how the code is able to distinguish a list value like eg. 5 from a following
file named 5. in the examples i saw that each list value is treated as a single argument, so the
option would even be --myList=2 3 4 5 (without any quotes).

for me it seems like a bug as the position of the options on the commandline should not determine
if a exception is thrown or not.

i am using jewelcli version 0.8.5 with jdk 1.7 on a xubuntu .

thanks in advance,

Arnd

[Tim Wood]

If I understand you correctly you have an ambiguity between the last  arguments being parsed as part of the list required by the list option and the list required by the unparsed option.

You can disambiguate by putting -- between the two lists e.g.

--myList 2 3 4 5 -- file1 file2 file3

Does this help?

--
You received this message because you are subscribed to the Google Groups "jewelcli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jewelcli+u...@googlegroups.com.
To post to this group, send email to jewe...@googlegroups.com.
Visit this group at http://groups.google.com/group/jewelcli?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Arnd]

no, in fact i was trying this before, but it does not help.

i guess a more robust solution would be to introduce something like a separator attribute in the Option annotation.
what if you have an List<String> with Strings containing spaces. i think there must be some possibility to configure a separator.
(of course this will rise up the question what happens if the separator character appears in a string, or more generally the topic escaping)
besides putting a -- would be a good workaround but not very intuitive for users that are no programmers.

Arnd 

[Tim Wood]

Makes sense. I think the -- end of options marker is quite standard, many command line argument libraries use this to disambiguate. In particular getopt, which is ubiquitous on unix systems, works this way. However I think having a configurable list separator would also be quite neat.

It would be very helpful for me if you could create a feature request on github for this issue. https://github.com/lexicalscope/jewelcli/issues

[Arnd]

ok, i will do tomorrow .
maybe you can give me a little hint which classes probably have to be modified.
1. i am curious, 2. i can mention them in the feature request
and 3. maybe i find time to contribute with implementing it, although i can't promise now ;-)

[Tim Wood]

I think its a reasonably big change. At the moment the parser is independent of the option specification, so the arguments are always parsed the same way. Then after that the validator checks that the arguments meet the specification, and then the argument presenter turns the parsed arguments into an instance of the specified interface (or sets them on the object).

So there is no control over the parser from the option specification. I think it will mean parameterizing the ArgumentParserImpl to allow the list separator to be configured, then changing the AbstractCliImpl to get the list separator from the specification and pass it to the parser. If you want per-option list separators then either the parser would have to be made aware of which option it is currently parsing, or some secondary parsing phase for list options could be introduced.

[Arnd]

yes, that sounds like a bigger change. meanwhile i was rethinking if i really need to configure the separator on option level.
to be able to configure it on a global level would already help, but i don't really see if this is minimizing the changes to be done.

imho the ArgumentParser should not even know that the option value has to be splitted into items. receiving an option like --myOption=1,2,3,4
should be delegated to the validator / parser as one string "1,2,3,4" leaving the splitting to them as they know the type of the option.
but of course i only take a short look at the code and don't know what this would implicate.

if configuring the separator on a global level does reduce required modifications i 'd prefer to request this as a feature.