Options with non-zero arity and no value supplied can consume other option names instead of producing an error about airline HOT 6 CLOSED

Most of the default option parsers are greedy and just attempt to consume the number of values required by the arity of the option without any real inspection of those values. So more specifically to your use case it doesn't try to disambiguate between the next token being a value vs it being another option.

So in your first case it sees --open and tries to parse a value for it but finds none thus you receive an error

In the second case it sees --open so grabs the next value which is --debug so your open option gets the value --debug and you don't receive an error

from airline.

But certainly this could be handled better, the default option parsers could check whether the next value is actually an option name and stop parsing further values if it is which should then generate the correct error in both cases

from airline.

So on thinking on this more I thought that the option parsers were supposed to be smart enough to check if the next token was an option and if so not treat it as a value. However it looks like one of the default parsers special cases the logic for arity = 1 to just consume the next token without that check.

So this is definitely a bug that wants fixing and I'll try to get this into the next release

from airline.

Changed needed:

• ClassicGetOptParser
• StandardOptionParser (special cases arity 1 options currently)
• ListValueParser
• MaybeListValueParser
• Unit test cases for this kind of error covering all built-in option parsers

from airline.

Should now be fully fixed on master, will push out a new bug-fix release shortly

from airline.

Fixed in 2.8.2 which is now released. It may take a couple of hours for artifacts to show up on Maven Central

from airline.