"eix --color -S" silently ignores -S

[jjakob]

For example: eix --color -S wayland finds only 18 matches, no errors, exit status is 0. eix -S wayland finds 62 matches. I assume --color is expecting an argument (never|always|auto) which silently swallows -S.

[vaeth]

Yes, this is how the argument parsing works. Works as intended.

[jjakob]

Wouldn't the expected result be an error? -S is not a valid setting for --color. Silently ignoring -S isn't something normal either.

[vaeth]

eix is alyways very gracious concerning arguments and variables: Unless it looks like a negative (starts with n[o], f[alse], of[f], is "-" or "0" or different cases) is recognized as a positive ("always"); in this particular case, there is a third case, namely if the argument starts with "au" which would mean "auto". For other boolean or 3-valued variables/arguments the parsing algorithm is similar; there is no "invalid argument" case - this is consistent across all of eix. So eix --color -S is effectively equivalent to eix --color always.

[jjakob]

Thanks for the explanation, that makes it clear why this doesn't produce an error. Personally I think it's not very user friendly to allow arbitrary values for settings that the man page only shows a finite amount of valid values. That would lead me to believe that only those values are valid and others will produce errors, as they do in other utilities, for example ls:

ls --color=x
ls: invalid argument ‘x’ for ‘--color’

ls does allow shorthand, so 'y', 'ye', 'yes', 'n', 'ne', 'nev' ... are all valid.

To not produce an error for arbitrary values I think isn't user friendly or intuituve, and would allow people to make "mistakes" like I did, without actually knowing they made a mistake.

I can't find it documented in the man page. --color only shows 3 valid values, no mention of allowing arbitrary values, or if the value can be ommitted, or what happens in that case.

It's also very unusual to allow the value to begin with a '-', which isn't usually allowed for value arguments separated by a space, those will get recognised by the parser as a separate option, not as the value of the previous option. A beginning '-' is only allowed when passed in the '--option=value' format.

[vaeth]

I think that it is more user-friendly to make sense of the argument even if the user does not remember it; and trying to be smarter as the user and doing some magic (as ls apparently does) is IMHO a bad idea.

I can't find it documented in the man page

A lot of corner cases and especially cases of "invalid" data/input are not documented and will never be.

those will get recognised by the parser as a separate option

If you were right, I would consider that command line parsing as broken as it behaves inconsistently for no reason. Standard libraries do not have the bug you describe, e.g. sed --file -a works as it should.

[jjakob]

I think that it is more user-friendly to make sense of the argument even if the user does not remember it; and trying to be smarter as the user and doing some magic (as ls apparently does) is IMHO a bad idea.

I would think that taking any value, even undocumented, random values, or other options, as valid input to an option that only takes 3 valid states, would be "trying to be smarter as the user". Especially assuming that any random value that the user passed in is actually "always" and not a typo of the user. This is not a filename, this is not an user-supplied data input, this is a setting that can have 3 states, so IMO it should throw an error if it's not set to one of those 3 states.

ls's handling of this I think is sensible, as it only takes shorted forms of the 3 valid states, but not any others.

If you were right, I would consider that command line parsing as broken as it behaves inconsistently for no reason. Standard libraries do not have the bug you describe, e.g. sed --file -a works as it should.

Your example: sed --file -a will produce an error if file -a doesn't exist, which is highly likely, if the user's intention was to actually use the flag -a. It won't get silently ignored.

[vaeth]

Your example: sed --file -a will produce an error if file -a doesn't exist, which is highly likely

So, what? If it would be unlikely they should have used a different parsing algorithm for that option? There would hardly be a better example of how trying to be smarter than the user would lead to inconsistent broken design.

Anyway, in eix the behavior of 2- and 3-valued variables is consistent, and this won't change, so there is no need in continuing this discussion.