better support for positional arguments

right now options which are based on their position rather than named; (i.e. @Parameter without a name) the current option is just to support a single @Parameter injection point which takes a List<String>

for commands where you expect positional arguments this loses lots of the benefit of the injection & type coercion & validation using the @Parameter annotation along with the nicely generated usage documentation.

It would be nice if we could supply an indexed parameter as opposed to a the named/optional parameter.

e.g.

class Copy {
  @IndexParameter(0, name = "from", "the source file(s) used to copy")
  File from;

  @IndexParameter(1, name = "to", "the destination file")
  File to;
}

So rather than having to manually parse a List<String> and figure out whats what, we can use the simpler annotation approach.

Also usage would be able to do something like…

Usage: copy [options] from to
    from   the source file(s) used to copy
    to       the destination file
  Options:    
    --bar        does something
    --another  something else

This also opens up the requirement for one of the parameters to be a collection, specifying minimum cardinality. e.g. you might want to do this…

class Copy {
  @IndexParameter(0, name = "from", "the source file(s) used to copy", arity = 1)
  List<File> from;

  @IndexParameter(1, name = "to", "the destination file")
  File to;
}

so that you could run the command

copy a b dest

but get an error you do any of the following

copy
copy a

[remkop]

All respect for JCommander, but if you’re interested in strong (and strongly typed) support for positional parameters you may be interested in picocli: http://picocli.info/#_options_and_parameters

[silasdavis]

There is an argument for convenience, for simple commands executed by hand you may not want the overhead of a flag, even a short one. There is also a justification in terms of command-line ‘polymorphism’ if for example a family of commands have a natural input and output. Or if a command works like an application of a function then you can write wrapper scripts that more naturally exploit this be not having to know the names of the operands.

More generally positional parameters are used widely in other unix tools to good effect. Sometimes the use of positional parameters highlights their primacy to the operation in question as opposed to flag parameters which are often seen as modifiers or auxillary.

So I’m not sure I agree that positional parameters are inferior a priori, although I can see why one might prefer named parameters in a number of cases.