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

Support argument aliases that set multiple arguments #1030

Closed
darnir opened this issue Aug 15, 2017 · 2 comments
Closed

Support argument aliases that set multiple arguments #1030

darnir opened this issue Aug 15, 2017 · 2 comments
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this

Comments

@darnir
Copy link

darnir commented Aug 15, 2017

Problem Description

In my projects, I often have a scenario where there is a single shortcut switch which sets values for multiple switches. For example, in my current project, I have (taken directly from my code):

        .arg(
            Arg::with_name("UTILIZATION")
                .long("utilization")
                .short("u")
                .takes_value(true)
                .overrides_with_all(&["UBEGIN", "USTEP", "UEND"])
                .help("Utilization of generated taskset"),
        )
        .arg(
            Arg::with_name("UBEGIN")
                .long("utilization-begin")
                .takes_value(true)
                .default_value("0.025")
                .help("Begin Utilization Range"),
        )
        .arg(
            Arg::with_name("USTEP")
                .long("utilization-step")
                .default_value("0.1")
                .help("Step for Utilization Range"),
        )
        .arg(
            Arg::with_name("UEND")
                .long("utilization-end")
                .default_value("1.0")
                .help("End of Utilization Range"),
        )
        .group(
            ArgGroup::with_name("UTILIZATION_RANGE")
                .conflicts_with("UTILIZATION")
                .multiple(true),
        )

Now what I would like it for the argument UTILIZATION to explicitly set values for UBEGIN, USTEP and UEND.

As you can see, I currently have a overrides and conflicts rule and then later in the application code, UTILIZATION is tested for and the other values are set.

Another way to implement this would be by allowing the user to manipulate values in the ArgMatches struct. Then one could simply set the values there before returning to the main client for consumption.

This is not a very obscure feature but is often used in many programs. For a more real-world usage of such a feature, please look at GNU Wget, quoting from its manual here (Emphasis mine):

  --mirror
       Turn on options suitable for mirroring.  This option turns on recursion and time-stamping, sets infinite recursion depth and keeps FTP
       directory listings.  It is currently equivalent to **-r -N -l inf --no-remove-listing**.
@kbknapp
Copy link
Member

kbknapp commented Oct 4, 2017

Using Arg::default_value_if will probably get you about 90% of what you're looking for. Otherwise, you'll have to go with defining these aliases in user code. I'm not against adding something like this feature in the future, but it's not something I can work on right now as there are about 1,000 other things I need to finish first 😜

@kbknapp kbknapp added A-parsing Area: Parser's logic and needs it changed somehow. P4: nice to have labels Oct 4, 2017
@pksunkara pksunkara removed the W: 3.x label Aug 13, 2021
@epage epage added C-enhancement Category: Raise on the bar on expectations and removed T: new feature labels Dec 8, 2021
@epage
Copy link
Member

epage commented Dec 9, 2021

Between default_value_if and replace (#2836), I think we've got this covered. If there is feedback on `replace, please put it there.

@epage epage closed this as completed Dec 9, 2021
@epage epage added the S-wont-fix Status: Closed as there is no plan to fix this label Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this
Projects
None yet
Development

No branches or pull requests

4 participants