Is it possible to require arguments to be "in order"?

[pfmoore]

I'm trying to emulate the argument structure of an existing command, which parses options at the start of the arguments, then a positional argument, followed by arbitrary other options, which are unparsed (specifically, they may look like options, but they are not to be treated as such). Something like

mycmd --option xxx positional a b --option c d

I want to get option being the list ["xxx"], my positional argument being positional and my "extra args" being ["a", "b", "--option", "c", "d"]. Basically the extra args are the arguments to a command specified in the positional argument.

Is this possible with clap? I don't want to debate whether this is a "good" CLI structure - I know it doesn't follow the normal (POSIX?) conventions, but matching the usage of some existing commands is the most important thing here, and I'm just hoping I don't have to implement my own argument parser just for this...

[epage]

This is not possible with clap.

[epage]

If you roll your own, I would recommend building on top of lexopt.

bpaf might be able to do this. Its built on the concept of combinators which lets you build up most of the parser by composing types which can handle some more custom cases without needing something built-in.

[pfmoore]

Actually, I found the following while looking for an alternative library:

    let matches = Command::new("pyr")
        .arg(Arg::new("include")
            .short('i')
            .long("include")
            .action(ArgAction::Append))
        .arg(Arg::new("script"))
        .arg(Arg::new("script_args")
            .action(ArgAction::Append)
            .trailing_var_arg(true)
            .value_delimiter(None))
        .get_matches();

The trailing_var_arg and value_delimiter calls on the script_args argument seem to do what I want. I don't fully understand why (the docs are comprehensive in terms of being an API reference, but there isn't that much tutorial or explanatory material available that I could find) but it's a start that I can work with.

[pfmoore]

... and after digging a bit further into the derive interface, the following also works (and is way simpler!):

#[derive(Parser, Debug)]
struct Args {
    #[arg(short, long)]
    include: Vec<String>,
    script: String,
    #[arg(trailing_var_arg=true, value_delimiter=None)]
    script_args: Vec<String>,
}

[epage]

Sorry, I hadn't realized you were just wanting to capture all trailing arguments but thought you had meant that named arguments must all come first and then positional arguments.

There is a tutorial but the challenge is finding the right depth for it. Covering every single feature or use case would be out of scope. Instead it focuses on getting started. The cookbook tries to help with special cases by finding commands people are used to and demonstrating the features through those.

[pfmoore]

No worries, a lot of my difficulty was knowing how to describe what I was trying to do (and hence not being able to formulate good searches!) so it's hardly surprising my explanation was unclear 🙂

Agreed it's hard to know how much to cover in a tutorial - while I've seen a few examples of this type of pattern, it's not common enough that I'd particularly expect it to be in a cookbook. What might have helped me is a glossary of terms - I didn't think of the term "vararg" for this type of argument (even though I'm familiar with the term from C) and I always find it difficult to know what to call an "argument", what to call an "option" and when to explicitly refer to "positional" arguments. Another useful document would have been a list of "features" supported by the library - the value_delimiter functionality is neat, and if I hadn't accidentally stumbled on it, I would have implemented it myself for my code without ever realising it existed as a built in capability.

But these are just ideas, take them if they are useful but ultimately I found out what I needed to know, so there's no problem either way.

[pfmoore]

And the final version, which is impressively straightforward:

struct Args {
    #[arg(short, long)]
    include: Vec<String>,
    script: String,
    #[arg(trailing_var_arg=true, allow_hyphen_values=true)]
    script_args: Vec<String>,
}

trailing_var_arg lets the last positional argument pick everything up, and allow_hyphen_values ensures that it accepts arguments with leading hyphens, rather than trying to parse them as options.

Sorry I didn't manage to find this myself in the first place - my search skills were obviously lacking. The key result that set me on the right path was here.