A duplicate option on the command line does not generate an error, and overwrites the original parsed value with the duplicate value.
[Edited for clarity]
Example: foo -o bar -o second_bar produces no error, and a single -o option "second_bar".
At worst, this should be an error, correct? At best, I'd like to collect an array of option values.
My workaround is to collect values in a static [String] array, ignore the value supplied by the parser, and convert the static array into parameters in the validate closure. But this is not ideal.
Some questions:
is it a bad idea to offer multiple "-o" options for my CLI?
Is the lack of an error message for multiple options worthy of a Bug Report on Github?
Is supporting multiple options worthy of a Feature Request on GitHub?
This is likely intended behavior, if I had to guess. See how git handles repeated options, which are explicitly designed to let you override a previous option later on the command-line.
You can always received all the options by using a String array like you indicated, which provides a fallback if you want other behavior, but personally I think allowing overrides is a sane default. That being said, I’m sure you’re welcome to file an issue or submit a pull request if you want to make it configurable.
And I may have misunderstood a portion of your initial question, so I just want to clarify: ArgumentParser supports arrays out of the box without any custom parsing. You can just set your property type to [String] and it’ll be automatically filled in by the parser and you can process it from there.
Apologies if that’s what you meant in the first place, I may not be understanding your description of parsing the array values.
No, you understood correctly. I want to capture all values from multiple options.
I'm wrestling with wether or not that's a good idea. If the norm is to replace, not accumulate, then I'll be bucking the norm.
OTOH my users are smart scientists, but not terminal-savvy. They might specify multiple option values as directed by the documentation "-o bar second_bar", or they may very well enter "-o bar -o second_bar". If I use the argument parser as is, then the latter will silently produce unexpected results.
It definitely seems reasonable to me to add an option to diagnose when the user provides multiple values for a non-array argument, even if the current behavior remains the default.