The following completion would happen (using example 17_yaml.rs):
```
$ prog <tab>
help subcmd
```
```
$ prog -<tab><tab>
--help -h (Prints help information)
--max-vals (you can only supply a max of 3 values for me!)
--min-vals (you must supply at least two values to satisfy me)
--mode (shows an option with specific values)
--mult-vals (demos an option which has two named values)
--option -o (example option argument from yaml)
--version -V (Prints version information)
-F (demo flag argument)
```
```
$ prog --<tab><tab>
--help -h (Prints help information)
--max-vals (you can only supply a max of 3 values for me!)
--min-vals (you must supply at least two values to satisfy me)
--mode (shows an option with specific values)
--mult-vals (demos an option which has two named values)
--option -o (example option argument from yaml)
--version -V (Prints version information)
```
```
$ prog --mode <tab>
emacs (shows an option with specific values) vi (shows an option with specific values)
```
```
$ prog subcmd -<tab>
--help -h (Prints help information) -B (example subcommand option)
--version -V (Prints version information)
```
```
$ prog subcmd --<tab>
--help (Prints help information) --version (Prints version information)
```
Close#578
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
Add the function `Arg.groups` that can take a `Vec<&'a str>` to add the `Arg` to multiple `ArgGroup`'s at once.
ex:
```rust
Arg::with_name("arg")
.groups(&["grp1", "grp2"])
```
Closes#426
In usage strings `[FLAGS]` and `[ARGS]` tags are now only added if there are relevant flags and
args to collapse. I.e. those that are
* Not required (`[ARGS]` only)
* Not belonging to some required group
* Excludes --help and --version (`[FLAGS]` only)
Closes#537
Previously, if one ran `<cmd> help help` an additional `help` subcommand was created and a help
message displayed for it. We *could* have just thrown an error `<cmd> help help` but I worry that
the message would be confusing, because something like, "Invalid Subcommand" isn't 100% correct as
the form `<cmd> help <subcmd>` is allowed, and there *is* a `help` subcmd.
This fix correct dispatches `<cmd> help help` to the `<cmd>` help message.
Closes#538
Prior to this fix, runnning `prog help subcmd` would produce:
```
subcmd
USGAE:
[...]
```
Notice lack of `prog-subcmd`. Whereas running `prog subcmd --help` produced:
```
prog-subcmd
USGAE:
[...]
```
These two forms now match the correct one (latter).
Closes#539
Now using `App::set_term_width` will set a wrapping width regardless of terminal size. This can
also be used when no terminal size can be determined (Such as on Windows). All help is now wrapped
at 120 if no terminal size has been specified, or can be determined.
Closes#451
This commit adds support for visible aliases, which function exactly like aliases except that they
also appear in the help message, using the help string of the aliased subcommand.
i.e.
```rust
App::new("myprog")
.subcommand(SubCommand::with_name("test")
.about("does testy things")
.alias("invisible")
.visible_alias("visible"));
```
When run with `myprog --help`, the output is:
```
myprog
USAGE:
myprog [FLAGS] [SUBCOMMAND]
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
SUBCOMMANDS:
help Prints this message or the help of the given subcommand(s)
test|visible does testy things
```
Closes#522
One can now use `AppSettings::DontDelimitTrailingValues` to stop clap's default behavior of
delimiting values, even when `--` or `TrailingVarArg` is used. This is useful when passing other
flags and commands through to another program.
Closes#511
Instead of blindly printing `[ARGS]` when only a single positional arg is present, it will now
print `[NAME]` (or `[NAME]...` for multiple values allowed)
Closes#518
Color are now only used when outputting to a termainal/TTY. There are three new settings as well
which can be used to control color output, they are:
* `AppSettings::ColorAuto`: The default, and will only output color when outputting to a terminal or TTY
* `AppSettings::ColorAlways`: Outputs color no matter where the output is going
* `AppSettings::ColorNever`: Never colors output
This now allows one to use things like command line options, or environmental variables to turn
colored output on/off.
Closes#512
Allows adding a subcommand alias, which function as "hidden" subcommands that automatically
dispatch as if this subcommand was used. This is more efficient, and easier than creating
multiple hidden subcommands as one only needs to check for the existing of this command,
and not all vairants.
Example:
```
let m = App::new("myprog")
.subcommand(SubCommand::with_name("test")
.alias("do-stuff"))
.get_matches_from(vec!["myprog", "do-stuff"]);
assert_eq!(m.subcommand_name(), Some("test"));
```
Example using multiple aliases:
```
let m = App::new("myprog")
.subcommand(SubCommand::with_name("test")
.aliases(&["do-stuff", "do-tests", "tests"]))
.get_matches_from(vec!["myprog", "do-tests"]);
assert_eq!(m.subcommand_name(), Some("test"));
```
Closes#469
For example, if an arg is part of a required group, it will only appear
in the group usage string, and not in both the group as well as the arg
by itself.
Imagine a group containing two args, `arg1` and `--arg2`
OLD:
`myprog <arg1> <arg1|--arg2>`
NEW:
`myprog <arg1|--arg2>`
Closes#498
Adds three new methods of `Arg` which allow for specifying three new
types of rules.
* `Arg::required_unless`
Allows saying a particular arg is only required if a specific other arg
*isn't* present.
* `Arg::required_unless_all`
Allows saying a particular arg is only required so long as *all* the
following args aren't present
* `Arg::required_unless_one`
Allows saying a particular arg is required unless at least one of the
following args is present.
Writing the help requires read only access to Parser's flags, opts
and positionals. This commit provides 3 functions returning iterators
over those collections (`iter_*`) allowing to have function outside
the parser to generate the help.
Passing empty values, such as `--feature ""` now stores the empty string
correctly as a value (assuming empty values are allowed as per the arg
configuration)
Closes#470
The `help` subcommand can now accept other subcommands as arguments to
display their help message. This is similar to how many other CLIs
already perform. For example:
```
$ myprog help mysubcmd
```
Would print the help message for `mysubcmd`. But even more, the `help`
subcommand accepts nested subcommands as well, i.e. a grandchild
subcommand such as
```
$ myprog help child grandchild
```
Would print the help message of `grandchild` where `grandchild` is a
subcommand of `child` and `child` is a subcommand of `myprog`.
Closes#416
By default `clap` now automatically wraps and aligns help strings to the
term width. i.e.
```
-o, --option <opt> some really long help
text that should be auto aligned but isn't righ
t now
```
Now looks like this:
```
-o, --option <opt> some really long help
text that should be
auto aligned but isn't
right now
```
The wrapping also respects words, and wraps at spaces so as to not cut
words in the middle.
This requires the `libc` dep which is enabled (by default) with the
`wrap_help` cargo feature flag.
Closes#428
Args and subcommands can now have their display order automatically
derived by using the setting `AppSettings::DeriveDisplayOrder` which
will display the args and subcommands in the order that they were
declared in, instead of alphabetical order which is the default.
Closes#444
Allows custom ordering of subcommands within the help message. Subcommands with a lower
value will be displayed first in the help message. This is helpful when one would like to
emphasise frequently used subcommands, or prioritize those towards the top of the list.
Duplicate values **are** allowed. Subcommands with duplicate display orders will be
displayed in alphabetical order.
**NOTE:** The default is 999 for all subcommands.
```rust
use clap::{App, SubCommand};
let m = App::new("cust-ord")
.subcommand(SubCommand::with_name("alpha") // typically subcommands are grouped
// alphabetically by name. Subcommands
// without a display_order have a value of
// 999 and are displayed alphabetically with
// all other 999 subcommands
.about("Some help and text"))
.subcommand(SubCommand::with_name("beta")
.display_order(1) // In order to force this subcommand to appear *first*
// all we have to do is give it a value lower than 999.
// Any other subcommands with a value of 1 will be displayed
// alphabetically with this one...then 2 values, then 3, etc.
.about("I should be first!"))
.get_matches_from(vec![
"cust-ord", "--help"
]);
```
The above example displays the following help message
```
cust-ord
USAGE:
cust-ord [FLAGS] [OPTIONS]
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
SUBCOMMANDS:
beta I should be first!
alpha Some help and text
```
Closes#442
Allows custom ordering of args within the help message. Args with a lower value will be
displayed first in the help message. This is helpful when one would like to emphasise
frequently used args, or prioritize those towards the top of the list. Duplicate values
**are** allowed. Args with duplicate display orders will be displayed in alphabetical
order.
**NOTE:** The default is 999 for all arguments.
**NOTE:** This setting is ignored for positional arguments which are always displayed in
index order.
```rust
use clap::{App, Arg};
let m = App::new("cust-ord")
.arg(Arg::with_name("a") // typically args are grouped by alphabetically by name
// Args without a display_order have a value of 999 and are
// displayed alphabetically with all other 999 args
.long("long-option")
.short("o")
.takes_value(true)
.help("Some help and text"))
.arg(Arg::with_name("b")
.long("other-option")
.short("O")
.takes_value(true)
.display_order(1) // Let's force this arg to appear *first*
// all we have to do is give it a value lower than 999
// any other args with a value of 1 would be displayed
// alphabetically with other 1 args. Then 2, then 3, etc.
.help("I should be first!"))
.get_matches_from(vec![
"cust-ord", "--help"
]);
```
The above example displays the following help message
```
cust-ord
USAGE:
cust-ord [FLAGS] [OPTIONS]
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
-O, --other-option <b> I should be first!
-o, --long-option <a> Some help and text
```
OsStr recently gained unstable inherent methods with the same name. This rename
makes sure we don't call the inherent methods but the methods provided by this
extension trait.
Adds a setting for both `AppSettings` and an `Arg` method which allows
placing the help text for a particular argument (or all arguments via
the `AppSettings`) on the line after the argument itself and indented
once.
This is useful for when a single argument may have a very long
invocation flag, or many value names which throws off the alignment of
al other arguments. On a small terminal this can be terrible. Placing
the text on the line below the argument solves this issue. This is also
how many of the GNU utilities display their help strings for individual
arguments.
The final caes where this can be hepful is if the argument has a very
long or detailed and complex help string that will span multiple lines.
It can be visually more appealing and easier to read when those lines
don't wrap as frequently since there is more space on the next line.
Closes#427
i.e. assume, option -O set to multiple, and number_of_values(1)
set. And assume a *required* positional argument is also set.
-O some -O other pos
Would fail with pos arg not supplied.
Relates to #415
By using AppSettings::AllowLeadingHyphen values starting with a
leading hyphen (such as a negative number) are supported. This
setting should be used with caution as it silences certain
circumstances which would otherwise be an error (like forgetting
a value to an option argument).
Closes#385
This commit adds support for values separated by commas such as
--option=val1,val2,val3. It also includes support for uses
without the equals and shorts (both with and without)
--option=val1,val2
--option val1,val2
-oval1,val2
-o=val1,val2
-o val1,val2
Closes#348
