Help with Arg::New -- second arg being required when I don't want it to be

[andrewschott]

So I have a little tool I slapped together to help me learn rust. I am running into an issue when creating my second arg list where the default_value is adhered to when nothing is passed at all, but when the first arg is listed I have to fill in the second. I have spent a good while scouring the documentation for something that may point me in the correct direction. So now I must e-beg :)

So here is what I have:

    let matches = command!()
        .arg(Arg::new("UPDATE_TOOL")
                .help("Which updater(s) to run")
                .value_parser(["all", "apt", "distrobox", "dnf", "flatpak", "firmware", "pacman","podman", "python","snap", "urpmi", "zypper"])
                .required(false)
                .default_value("all")
                .action(ArgAction::Append)
        )
        .arg(Arg::new("OUTPUT")
                .help("Where to send the output")
                .value_parser(["terminal", "logfile", "both", "silent"])
                .required(false)
                .default_value("terminal")
                .action(ArgAction::Set)
        )
        .get_matches();

My intention is to have it when invoked with no parameters run it as if "all" and "terminal" are selected (which works), and if something needs to be specified, act differently accordingly. So if I invoke it with "dnf" only, to expect the output to be "terminal" (this does not work). But I am being forced to specify both on the cli. So in the latter's case, I must invoke with "dnf terminal", for example. I want to be able to just go "dnf" and have it expect report back as terminal, which the rest of my program can handle dealing with (which it pretty much does).

The problem is how can I make the second parameter (and presumably if I need 3rd, 4th, ....) not be required when the first one is specified?

Sample of what I mean:

# ./target/release/osupdater dnf
error: invalid value 'dnf' for '[OUTPUT]'
  [possible values: terminal, logfile, both, silent]

For more information, try '--help'.

# ./target/release/osupdater dnf terminal
Application started at 2024-12-27-22-37-26

TIA!
Andrew.

[epage]

This is an ambitious situation in the parser. Unless we check the parse result and rely on the user correctly typing answers for the first parameter, there is no clear way to say whether the last argument is part of the first Arg or the second.

We don't check the parse result for a couple of reasons

• Historical
• Error messages
• That can still be ambiguous
• Some users are sensitive to what clap over-parsing

I wouldn't have been able to say what we do in this situation because the nuance involved in that part of the code. If we didn't have the logic to assume the user meant the last positional, the alternative would likely have been an assert since then we could never reach the last argument.

A workaround is to use one argument and to override the usage to show it as two.

[andrewschott]

Thank you for the response. Until I can find a way to keep things simple, I will gut that portion of the code. Thanks for the honest and complete reply. And, yeah I get it. Can't please everyone and a choice had to be made. And now I know it was made and why.

You mentioned

A workaround is to use one argument and to override the usage to show it as two.

This is interesting, do you have an example of what you mean here? In case it wasn't clear, I am a bit of a moron when it comes to coding to start with, and an absolute noob when it comes to clap and rust in particular.

Thanks again for the prompt and honest reply!

[epage]

Docs for override_usage are at https://docs.rs/clap/latest/clap/struct.Command.html#method.override_usage

It would look something like

    let matches = command!()
        .override_usage("osupdater [OPTIONS] [UPDATE_TOOL]... [OUTPUT]")
        .arg(Arg::new("args")
                .value_names(["UPDATE_TOOL", "OUTPUT"])
                .action(ArgAction::Append)
        )
        .get_matches();

Then split args up as you need