1

Hi, I'm new here.

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?
  • Should I just dive in, branch, and submit a PR?

Thanks

2

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.

3

Makes sense. Thanks for the feedback.

4

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.

1 Like
5

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.

6

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.

1 Like