Allow final argument to be a command

[Diggsey]

AFAICT, it's not possible to define a CLI such as the following:
myprogram <arg> <command>

Here, command may include any number of arguments or flags, which clap should not attempt to interpret.

The first argument which does not begin with -, when all positional arguments have already been encountered, indicates the start of the command, and all subsequent arguments will be passed-through unchanged.

Alternatively, if -- occurred previously, and all positional arguments have already been encountered, then the next argument, regardless of whether it starts with -, indicates the start of the command.

eg.
myprogram a -t b - Error, -t is not recognised
myprogram -- a -t b - Valid, command is -t b
myprogram a - Error: no command present (if command is a required arg)
myprogram a b -t - Valid, command is b -t

[sru]

@Diggsey is it possible to pass the command as one argument? i.e. using double quotes

Currently, Clap cannot allow the final argument to have the rest of argument to pass off as one argument.

We could also expose the arguments the are left over as extra.

[Diggsey]

Is it possible to pass the command as one argument? i.e. using double quotes

No, that would make escaping too painful, and I'm trying to mirror an existing CLI.

Currently, Clap cannot allow the final argument to have the rest of argument to pass off as one argument.

That's why I opened the issue... Or do you mean it can't add support for that for some reason? I had a brief look at the parsing code and it didn't seem particularly problematic to add support for this.

[sru]

I see. No, I think it should be easy to add support for this.

[kbknapp]

This is already somewhat possible with --.

Example:

let m = App::new("test").arg_from_usage("<cmd>... 'some cmd'").get_matches();
if let Some(v) = m.values_of("cmd") {
    for cmd in v {
        println!("{}", cmd);
    }
}

Then running

$ test -- some -a -t cmd this that --long=this --testing
some
-a
-t
cmd
this
that
--long=this
--testing

[kbknapp]

@Diggsey is the current -- enough for your usage? If so, we can close this issue.

I am hesitant to add special case rules for this problem set which I would imagine is a rare case. Reason being, there may be cases when a user typos more positional than expected, and to have it automatically start parsing as a command could have very undesirable results.

I'm not saying we wouldn't add it, but that we'd need to discuss the implementation before-hand.

[Diggsey]

is the current -- enough for your usage? If so, we can close this issue.

Not really - for the moment I've worked around it by detecting that case and intercepting it before I invoke clap.

there may be cases when a user typos more positional than expected, and to have it automatically start parsing as a command could have very undesirable results.

Presumably it would be opt-in: it would only start parsing as a command if the current subcommand expected to take a command as input.

[kbknapp]

Presumably it would be opt-in: it would only start parsing as a command if the current subcommand expected to take a command as input.

I'm OK with it being an opt-in setting. I'll set this for the 1.4.4 release, since it may take a little more time to implement.

[kbknapp]

Here's the implementation that #301 contains:

Using the AppSettings::TrailingVarArg setting enables:

• Final positional argument "eats" all other arguments without the need for --

extern crate clap;

use clap::{App, AppSettings};

fn main() {
    let m = App::new("test")
        .setting(AppSettings::TrailingVarArg)
        .args_from_usage(
         "[arg1]         'some arg'
          [CMD]...       'arguments to pass to the CMD'")
        .get_matches();
    for a in m.values_of("CMD").unwrap() {
        println!("{}", a);
    }
}

Running with:

$ test some_arg cmd -H 20 --long value
cmd
-H
20
--long
value

The initial arg1 is just to show that it works even with other positional args defined.

@Diggsey @matklad

IF THIS DOES NOT SOLVE THIS ISSUE: let me know so that we can fix before the merge. One caveat, is I don't want to special case too heavily if there are things that can be done in downstream code.

[Diggsey]

@kbknapp Wow that looks perfect, thanks. Feel free to close this when those changes get merged in.

[kbknapp]

@Diggsey will do, let us know if you have any issues 😉