Parse a Vec<T> out of a single comma-delimited argument without consuming the rest

[stijndcl]

I'm working on a CLI interface that takes multiple consecutive parameters that are comma-delimited lists. These are consecutive positional arguments, followed by some other positional arguments.

Example usage: ./tool a,b,c 1,2,3 /out.

This is the current setup I'm using:

#[derive(Parser, Debug)]
struct Cli {
    #[clap(num_args = 1.., value_delimiter = ',')]
    first: Vec<String>,
    #[clap(num_args = 1.., value_delimiter = ',')]
    second: Vec<u64>,
    third: PathBuf,
}

Usually spaces are used to delimit values in vectors, so it is ambiguous which value belongs to which vector. As a result, first swallows everything and second and third throw an error saying the value is missing.

In my case, I want spaces to denote the end of an argument - solely relying on the commas to delimit items in a list. I hoped value_delimiter = ',' would do this for me but it does not - values separated by commas are grouped together correctly, but the remaining arguments are still swallowed.

I also tried using value_terminator = ' ' to force it to stop looking after hitting a space, but that did nothing either.

Is there a way to get the behaviour I want without enforcing --long argument usage (keeping it positional as in the example above)?

I could use String as the type and parse it into a Vec<String> afterwards using split(), but I'd like for Clap to handle this for me instead if possible. Also, using a Vec over a String makes the help formatter show explicitly that an argument will take multiple values, which is a feature I don't want to lose out on.

[epage]

Set num_args = 1. num_args is how many raw arguments you want to consume, rather than validation on how many values you did consumed.

[stijndcl]

Nope, using num_args = 1 with my above input gives this error:

error: the following required arguments were not provided:
  <SECOND>...
  <THIRD>

indicating that everything was consumed into the first argument. Commenting out the other fields and printing first confirms this as well:

fn main() {
    let args = Cli::parse();
    println!("{:?}", args.first);
}

#[derive(Parser, Debug)]
struct Cli {
    #[clap(num_args = 1, value_delimiter = ',')]
    first: Vec<String>,
    // ... here be commented out second and third arg
}

Output:

$ ./tool a,b,c 1,2,3 /out
["a", "b", "c", "1", "2", "3", "/out"] # Expected output for the first argument is just ["a", "b", "c"].

[epage]

Check out the arg types referencehttps://docs.rs/clap/latest/clap/_derive/index.html#arg-types). You'll need to undo what it does. In particular, you also need to set ArgAction::Set.

#4626 is the issue trying to figure out a way to improve this.

[faultymajority]

It seems like command --arg x,y -- z also works, would this be intended?

[epage]

Your command-line output uses --arg, did you mean

#[derive(Parser, Debug)]
struct Cli {
    #[clap(long, num_args = 0.., value_delimiter = ',')]
    arg: Vec<String>,
    positional: String
}

[epage]

Also, could you specify your arguments, as in provide a written description of how you expect them to behave? That would help understanding the code you provided (e.g. why num_args is used).

[faultymajority]

The expectation I think shared by this discussion is that an invocation command --arg x,y z or command --arg x --arg y z would place ["x", "y"] in Cli.arg and "z" in Cli.positional. The arg is intended to be an optional positional argument, that can be repeated (either via comma-separation --arg x,y or full repetition --arg x --arg y).

However, again as I believe to be the topic of this thread, the actual outcome is that the required positional argument is reported as "missing" (clap seems to try to put ["x", "y", "z"] in Cli.arg).

My comment was trying to be helpful, as I had discovered two syntaxes that result in an outcome meeting the expectation (x/y in arg, z in positional), namely --arg=x,y z and --arg x,y -- z. I found it surprising that these two do work (as I'd consider the = in --arg=... to be equivalent to whitespace).

[epage]

What was shared before was a couple of examples.

So to re-phrase from these more detailed examples

• --arg is an option (not positional) that can be repeated and takes delimited values
• <positional> is a required positional that takes a single value

In your case, it sounds like num_args is not relevant to your needs and is the source of your problems, see num_args docs.

As for the behavior with = that is intentional that no more arguments are treated as values to an option if = is used. Otherwise you could do --arg=x y z and that would be treated as arg: ['x', 'y', 'z'] but looking at it, it appears that only x is relevant to --arg.

[faultymajority]

Oh that's interesting - removing num_args=0.. indeed fixes the problem for me, thank you!