Automatic binding of consecutive parameters to collection

[Starkie]

Some CLI programs infer that a list of consecutive parameters belong to the same option. For example, the program cp in unix has the following profile, were one or more source files can be specified to be copied to directory:

cp [OPTION]... SOURCE... DIRECTORY

The usage would be as following:

cp file1 file2 directory

I tried to implement a similar behaviour in a command line program, that receives a collection of paths:

static void Main(string[] paths)
{
  // Do something
}

I expected to invoke the program like this:
dotnet run -- --paths file1 file2 file3

But instead, the argument name had to be specified each time:
dotnet run -- --paths file1 --paths file2 --paths file3

Does a way to implement options with a similar behaviour exist?

Might be related to #310.

[jonsequitur]

Yes, I think #310 is related, although we haven't discussed enabling this for options, just for commands. #310 will allow command arguments to differ by type, name, and arity, so in your first example, the cp command would accept an Argument<FileInfo[]> and a second Argument<DirectoryInfo>.

The behavior you're describing is currently available in a limited way for command arguments if the Command.Argument.Arity is greater than 1 (e.g. Argument<string[]>), but without #310, your program will have to do its own interpretation of the arguments, and help isn't yet able to differentiate them. But at the moment cp could look like this:

var cp = new Command("cp")
{
    Argument = new Argument<string[]>()
};

Do you have any examples where you would expect the option arguments to similarly be able to differ by type?

Also related: #37

[Starkie]

#310 will allow command arguments to differ by type, name, and arity, so in your first example, the cp command would accept an Argument<FileInfo[]> and a second Argument<DirectoryInfo>.

I'm not sure I understand correctly this part. Does this mean that both types could match to the same --paths argument in the same command invocation? Or would that be the same command with a different "profile"?

I'll check the workaround you provided when I get the time. Is there something similar for the DragonFruit model? It's the one we are currently using.

Do you have any examples where you would expect the option arguments to similarly be able to differ by type?

In my use case, no. The inputs of the argument are all of the same type.

Here's the link of the PR where I'm using the library, in case it is of any use. https://github.com/Starkie/DuplicateExtensionFinder/pull/1

[jonsequitur]

I'm not sure I understand correctly this part. Does this mean that both types could match to the same --paths argument in the same command invocation? Or would that be the same command with a different "profile"?

It would be the same command, so for example given a tool like this, where source_file and target_dir are arguments:

usage: cp source_file target_dir

it might bind to a command handler like this:

void copy( FileInfo source_file, DirectoryInfo target_dir ) { }

[Starkie]

Oh, sorry for the confussion: In my C# example I didn't specify the target_dir that I mentioned in cp. 😅
But yes, I think that would be a valid model to represent this command.

[jonsequitur]

I'm closing this as I believe it's a duplicate of #310. Please reopen if you think I might be overlooking some detail.