Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Override setting for groups #1023

Open
Phlosioneer opened this issue Aug 9, 2017 · 4 comments
Open

Feature Request: Override setting for groups #1023

Phlosioneer opened this issue Aug 9, 2017 · 4 comments
Labels
A-builder Area: Builder API A-validators Area: ArgMatches validation logi C-enhancement Category: Raise on the bar on expectations E-medium Call for participation: Experience needed to fix: Medium / intermediate

Comments

@Phlosioneer
Copy link
Contributor

Phlosioneer commented Aug 9, 2017

There are many instances of command line utilities that have groups of flags, all able to override each other.

For example, as mentioned in this issue, the od utility has 10 flags that all override each other: abcdfilosx. The last appearing flag is the one that is used. Likewise, the ls utility has similar "groups" of overriding flags: ls manual

It is not an error to specify more than one of the following mutually exclusive options:
-1, -C, -g, -l, -m, -n, and -x; and -c, -f, -S, -t, and -u. Where more than one option is specified
from the same mutually exclusive group, the last option given overrides the others, except
that -l always overrides -g; and -f always overrides -c, -S, -t, and -u.

If this feature existed, one could input it into clap like this:

// Note, my syntax might not be perfect.
let foo = App::new("ls")
  .args(&["1", "C", "g", "l", "m", "n", "x"])
  .group(ArgGroup::with_name("formatting")
    .override_with_self(true);  // New feature.
  );

This is technically already do-able; just set every individual argument to overload every other argument. However, that's inefficient, unreasonably difficult to input, and grows faster than exponentially.

The proposed feature would be one new function: ArgGroup::override_with_self(value: bool) -> Self.

Implementation for just flags would imply Arg::multiple(true) for its args and then simply force ArgMatches::value_of to return the last parsed value. It may be more complicated to account for arguments with values (--foo bar)? I'm not familiar with the internal workings of clap-rs, so I don't know how difficult it would be to add this feature.

This feature would be very useful when re-writing old command-line apps, as this kind of group-override pattern shows up a lot.

@kbknapp
Copy link
Member

kbknapp commented Oct 4, 2017

I like this idea! It would also help with a similar issue I had when converting exa to use clap. I can't say I'll implement this tomorrow, as my plate is super full, but I do want this feature think it'd making specifying these large groups of overrides much easier.

Thanks for the details and the suggestion! 👍

@kbknapp kbknapp added C: arg groups C-enhancement Category: Raise on the bar on expectations labels Oct 4, 2017
@Phlosioneer
Copy link
Contributor Author

Phlosioneer commented Oct 4, 2017

Note: another option is to simply have a method like ArgMatches::values_of_group that just lists the command matches, in order, within the group, and their values. Then the application can worry about overrides; this would help in particular with nasty corner cases like the above "except that -l always overrides -g" etc.

this option exposes more API to worry about... but, there's very little state to keep track of, so parsing logic might be made easier. Still not familiar with the internals of clap, though.

@kbknapp
Copy link
Member

kbknapp commented Oct 4, 2017

Values can already be checked by group, but since it's a relatively unused feature (or rather undocumented feature) I can't speak to any edge case bugs that exist.

matches.value_of("group") should work for testing purposes.

@Phlosioneer
Copy link
Contributor Author

good to know, thanks.

@kbknapp kbknapp added W: 3.x and removed W: 2.x labels Jul 22, 2018
@pksunkara pksunkara added this to the 3.1 milestone Apr 9, 2020
@pksunkara pksunkara removed the W: 3.x label Aug 13, 2021
@epage epage added A-builder Area: Builder API A-validators Area: ArgMatches validation logi E-medium Call for participation: Experience needed to fix: Medium / intermediate and removed C: arg groups labels Dec 8, 2021
@epage epage removed this from the 3.1 milestone Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-builder Area: Builder API A-validators Area: ArgMatches validation logi C-enhancement Category: Raise on the bar on expectations E-medium Call for participation: Experience needed to fix: Medium / intermediate
Projects
None yet
Development

No branches or pull requests

4 participants