Varargs positional arguments consume unmatched options

[smowton]

This is an extension of b287f78

When consuming arguments for a varargs positional argument you check that the next arg isn't a recognised option, but not whether it resembles an option.

Thus mycmd --real-option arg and mycmd arg --real-option are handled symmetrically (one positional arg and one option consumed), but mycmd --no-such-option arg and mycmd arg --no-such-option are not (1 unmatched, 1 positional and 0 unmatched, 2 positional respectively).

[remkop]

This issue is similar to #639 (which started out about multi-value options with arity = "*" consuming values that resemble options, and later found that single-value options that take a String parameter will also consume a value that resembles an option).

So, yes, currently values that "resemble" options are consumed, and only values that exactly match an option name will cause a varargs option or positional parameter to stop consuming values.

One idea to improve this is to have a consumeUnmatchedOptionsInVarargs property in ParserSpec (and perhaps CommandLine.get/setConsumeUnmatchedOptionsInVarargs methods). This property would be true by default, to keep the current behaviour.

When this property is set to false, a value that "resembles" an option would be treated as unmatched input, which would either throw an UnmatchedArgumentException (resulting in a nice user-facing message) or cause the value to be added to the unmatched arguments list, depending on how the application is configured via CommandLine.setUnmatchedArgumentsAllowed(true/false).

This is on the roadmap but I won't be able to spend time on it in the near future. If this interests you, and you feel like helping to improve this, please consider submitting a pull request. 😉

[smowton]

I think consumeUnmatchedOptionsInVarargs is effectively a duplicate of unmatchedOptionsArePositionalParams, no? Personally I'd view the current situation as a bug: most argparse-type libraries (that support intermixed positionals and options at all) would object to somearg --somenonsense the same as --somenonsense somearg, but obviously your call as to the primacy of expected behaviour for newcomers vs. not surprising upgraders.

[remkop]

I think consumeUnmatchedOptionsInVarargs is effectively a duplicate of unmatchedOptionsArePositionalParams, no?

The problem is that while processing varargs, the parser is not watching for unmatched options. The unmatchedOptionsArePositionalParams property only takes effect when an arg is recognized as an "unmatched option". I think these need to be separate parser properties.

I'd view the current situation as a bug

Varargs have limitations. I would agree we had a bug if vararg options were consuming subcommands or real options. With arguments that "look like options" I think the current behaviour is one reasonable way to do it.

That said, I am happy to improve things. At some point I will probably add a configuration like we discussed above to make the parser check for arguments that "look like options" before letting varargs consume such arguments. I just don't know when I will get to it.

If this is important to you, I encourage you to dive in and contribute a PR. It may be easier than you think! 😉

[remkop]

Looking at this and similar issues (#639 and #1055) now.

Reading your comment again I like your idea of consistently rejecting both mycmd --no-such-option arg and mycmd arg --no-such-option unless unmatchedOptionsArePositionalParams=true, rather than introducing another parser option.