Adds a crate_authors! macro that fetches
crate authors from a (recently added)
cargo enviromental variable populated
from the Cargo file. Like the
crate_version macro.
Closes#447
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
Now if the terminal size is too small to properly wrap the help text
lines, it will default to just wrapping normalling as it should.
This is determined on a per help text basis, so because the terminal
size is too small for a single argument's help to wrap properly, all
other arguments will still wrap and align correctly. Only the one
affected argument will not align properly.
Closes#453
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
When value names are use, they will be displayed in help and error
messages instead of the argument name. For example, an argument named
`arg` but with the value name `FILE` will be displayed as `[FILE]`.
Likewise multiple value names will be displayed properly such as `[FILE1] [FILE2]`
Closes#420
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
ArgGroups can now be built from standalone YAML documents. This is
labeled as a fix because it should have been the case prior. A
standalone YAML document for a group would look something like
```
name: test
args:
- arg1
- arg2
required: true
conflicts:
- arg3
requires:
- arg4
```
This commit also keeps support building groups as part of a larger
entire App YAML document where the name is specified as a key to the
yaml tree
The method `starts_with` as implemented for the `OsStrExt2` trait on
`OsStr` assumed that the needle given is shorter than the haystack. When
this is not the case, the method panics due to an attempted
out-of-bounds access on the byte representation of `self`. Problematic
if, say, an end-user gives us `"-"` and the library tries to see if that
starts with `"--"`.
Fortunately, slices already implement a `starts_with` method, and we can
delegate to it.
This *does* create a semantics change: if both `self` and the needle
have length 0, this implementation will return `true`, but the old
implementation would return `false`. Based on the test suite still
passing, acknowledging the vacuous truth doesn't seem to cause any
problems.
Fixes#410
External subcommands are now supported via the following:
```rust
extern crate clap;
use clap::{App, AppSettings};
fn main() {
// Assume there is a third party subcommand named myprog-subcmd
let m = App::new("myprog")
.setting(AppSettings::AllowExternalSubcommands)
.get_matches_from(vec![
"myprog", "subcmd", "--option", "value", "-fff", "--flag"
]);
// All trailing arguments will be stored under the subcommands sub-matches under a
// value of their runtime name (in this case "subcmd")
match m.subcommand() {
(external, Some(ext_m)) => {
let ext_args: Vec<&str> = ext_m.values_of(external).unwrap().collect();
assert_eq!(ext_args ,["--option", "value", "-fff", "--flag"]);
},
_ => unreachable!()
}
}
```
Closes#372
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
Tons of code has been moved into functions, deduplicated, made much
easier to read, maintain, and understand. Comments still need to be
added, but that will happen shortly. Modules have also been moved around
to follow Rust conventions and best practices.
All functionality remains exactly the same
There is now an AnyArg trait which lets you (clap dev, not consumer) get
info about certain args regardless of their type. Allows more generic
and de-duplicated code
As of https://github.com/rust-lang/cargo/pull/1094, cargo publishes the full crate version as `CARGO_PKG_VERSION`, rather than *just* the parts of it.
This replaces the more complicated call with simply `env!("CARGO_PKG_VERSION").to_owned()`.
Now you can use get_matches_safe instead of get_mathces if you want
to handle errors yourself.
This will allow now to write false-negative tests and check what type
of error occurs
Allows setting `Arg::number_of_values(qty)` where `qty` < 2. This allows
things such as `Arg::number_of_values(1)` in conjuction with
`Arg::multiple(true)` which would make invoking the program like this
`myprog --opt val --opt val` legal, but `myprog --opt val1 val2`
illegal.
Closes#161
Long help strings can now be broken up with newlines that will be
properly aligned in help messages. Simply place a `{n}` wherever you'd
like the newline to appear.
Closes#145
Allows creating help messages with a more unified look, similar to how
docopt and getopts are formatted. (i.e. flags and options are combined
into a single group)
Closes#158
In order to pause for user input on error use `.wait_on_error(true)` but
it's important to note that this is *not* recursive through subcommands.
This is useful on Windows when a user mistakenly opens an application by
double clicking it, instead of using the command line or if using a GUI
shortcut to run a program.
Closes#140
The new default short for version is `-V` (capital). This is a "breaking"
change at least for documentation.
If the old lowercase `-v` is desired you can manually override with
`App::version_short("v")`
The help short can also be overridden now too.
BREAKING CHANGE
You can now use ArgName::variants() to get a Vec<&'static str> of
vairant names (Nice for Arg::possible_values()). It's not as good as
implementing Iterator for the enum, but that can't be done without being
able to concat AST tokens in order to make an "EnumIter" type which
implements iterator and keeps track of when to yield None. But the
overall intent of this issue was to be able to iterate variant names,
which is now possible.
Closes#119
