* test: `require_unless_one` with second argument
Add the `require_unless_one_2` test. This tests that when the second
argument in the array is used at the command line, that the required
argument is not present. This test was added because it appears the
`require_unless_one` function only works for the first argument in the
array.
* Fix: assertions for test
The assertions did not check for the `infile` to be present.
add `gen_completions_to`
to write completions to buffer (e.g. stdout) instead of file. fixes#566
(for review; will fix commit message when done)
still pretty new to rust so comments on anything from style to structure would be must appreciated!
Fix the formatting in the completions example
A missing newline prevented the Cargo.toml excerpt in the `gen_completions` example from being properly formatted.
Aliases to subcommands can now be completed just like the original subcommand they alias.
Imagine a subcommand `update` with alias `install`, the `update` subcommand has an option `--pkg`
which accepts a package to update/install.
The following completion would happen:
```
$ prog <tab><tab>
-h --help -V --version install update
$ prog install <tab><tab>
-h --help -V --version --pkg
$ prog install --pkg <tab><tab>
$ prog install --pkg <PACKAGE>
$ prog update <tab><tab>
-h --help -V --version --pkg
$ prog update --pkg <tab><tab>
$ prog update --pkg <PACKAGE>
```
Closes#556
Prior to this change, completions only allowed one completion per command, this change allows as
many as required. The one downside to this change is the completion engine isn't smart enough to
determine which options are no longer legal after certain options have been applied.
Now when one completes an option with possible values, those values will be displayed. Imagine
a program with an `--editor` option, which accepts either `vi`, or `emacs`. The following would
be displayed for completions
```
$ prog --editor <tab><tab>
vi emacs
```
Closes#557
By using a build.rs "build script" one can now generate a bash completions script which allows tab
completions for the entire program, to include, subcommands, options, everything!
See the documentation for full examples and details.
Closes#376
Using this setting requires a value delimiter be present in order to parse multiple values.
Otherwise it is assumed no values follow, and moves on to the next arg with a clean slate.
These examples demonstrate what happens when `require_delimiter(true)` is used. Notice
everything works in this first example, as we use a delimiter, as expected.
```rust
let delims = App::new("reqdelims")
.arg(Arg::with_name("opt")
.short("o")
.takes_value(true)
.multiple(true)
.require_delimiter(true))
// Simulate "$ reqdelims -o val1,val2,val3"
.get_matches_from(vec![
"reqdelims", "-o", "val1,val2,val3",
]);
assert!(delims.is_present("opt"));
assert_eq!(delims.values_of("opt").unwrap().collect::<Vec<_>>(), ["val1", "val2", "val3"]);
```
In this next example, we will *not* use a delimiter. Notice it's now an error.
```rust
let res = App::new("reqdelims")
.arg(Arg::with_name("opt")
.short("o")
.takes_value(true)
.multiple(true)
.require_delimiter(true))
// Simulate "$ reqdelims -o val1 val2 val3"
.get_matches_from_safe(vec![
"reqdelims", "-o", "val1", "val2", "val3",
]);
assert!(res.is_err());
let err = res.unwrap_err();
assert_eq!(err.kind, ErrorKind::UnknownArgument);
```
What's happening is `-o` is getting `val1`, and because delimiters are required yet none
were present, it stops parsing `-o`. At this point it reaches `val2` and because no
positional arguments have been defined, it's an error of an unexpected argument.
In this final example, we contrast the above with `clap`'s default behavior where the above
is *not* an error.
```rust
let delims = App::new("reqdelims")
.arg(Arg::with_name("opt")
.short("o")
.takes_value(true)
.multiple(true))
// Simulate "$ reqdelims -o val1 val2 val3"
.get_matches_from(vec![
"reqdelims", "-o", "val1", "val2", "val3",
]);
assert!(delims.is_present("opt"));
assert_eq!(delims.values_of("opt").unwrap().collect::<Vec<_>>(), ["val1", "val2", "val3"]);
```
Imagine two args, an option `-o` which accepts mutliple values, and a positional arg `<file>`.
Prior to this change the following (incorrect) parses would have happened:
```
$ prog -o 1,2 some.txt
o = 1, 2, file
file =
```
Only when delimters are used, spaces stop parsing values for the option. The follow are now correct
```
$ prog -o 1,2 some.txt
o = 1, 2
file = some.txt
$ prog some.txt -o 1 2
o = 1, 2
file = some.txt
```
This still has the bi-product of:
```
$ prog -o 1 2 some.txt
o = 1, 2, some.txt
file =
```
This is simply a CLI design and documentation issue (i.e. don't allow options with unlimited
multiple values with positionaln args, or clearly document that positional args go first). This
will also be helped by the upcoming `Arg::require_delimiter`
Relates to #546
Imagine two args, an options `-o` and a positionanl arg `<file>` where the option allows multiple
values. Prior to this change the following (incorrect) parses were occurring:
```
$ prog -o=1 some.txt
o = 1, file
file =
```
This change stops parsing values at the space, only if the `=` was used.
```
$ prog -o=1 some.txt
o = 1
file = some.txt
```
Multiple values are still supported via value delimiters
```
$ prog -o=1,2 some.txt
o = 1, 2
file = some.txt
```
Relates to #546
