One can now use `App::long_version` to dsiplay a different (presumably
longer) message when `--version` is called. This commit also adds the
corresponding print/write long version methods of `App`
One can now use `App::print_long_help` or `App::write_long_help`
Note that `App::write_long_help` is **NOT** affected by kbknapp/clap-rs#808 in the manner
that `App::write_help` help is and thus should be preferred if at all possible.
One can now use `Arg::long_help` which will be displayed when the user
runs `--help`. This is typically longer form content and will be
displayed using the NextLineHelp methodology.
If one specifies the standard `Arg::help` it will be displayed when the
user runs `-h` (by default, unless the help short has been overridden).
The help text will be displayed in the typical clap fashion.
The help format requested (-h/short or --help/long) will be the
*default* displayed. Meaning, if one runs `--help` (long) but only an
`Arg::help` has been provided, the message from `Arg::help` will be
used. Likewise, if one requests `-h` (short) but only
`Arg::long_help` was provided, `Arg::long_help` will be displayed appropriately
wrapped and aligned.
Completion script generation *only* uses `Arg::help` in order to be
concise.
cc @BurntSushi thanks for the idea!
One should be able to override the auto generated help and version flags
by simply providing an arg with a long of `help` or `version`
respectively. This bug was preventing that from happening.
However, now that it's fixed if one was relying on adding an arg with a
long of `help` or `version` and using `get_matches_safe` to produce the
`ErrorKind::HelpDisplayed` or `ErrorKind::VersionDisplayed` errors they
**WILL NOT** happen anymore.
This is because the bug was causing those "errors" to occur (i.e. the
help or version message to be displayed). The "fix" to get that
functionality back is to either:
* Remove the arg with the long of `help` or `version`
* Use `ArgMatches::is_present` instead of `App::get_matches_safe` to check for the presence of your custom help or version flag
Option 1 is the easiest provided one wasn't using said arg to *also*
override other aspects of the flags as well (short, help message, etc.)
Even though this may break some code, as per the compatibility policy
listed in the readme; code that breaks due to relying on a bug does
*not* constitute a major version bump. I will however be bumping the
minor version instead of just the patch version. I will also be
searching for, contacting, and attempting to submit PRs to any affected
projects prior to releasing the next version to crates.io
Closes#922
Adds a new method, `Arg::hide_default_value`, which allows for
specifying whether the default value of the argument should be hidden
from the help string.
Closes#902
Marking a positional argument `.last(true)` will allow accessing this argument earlier if the `--` syntax is used (i.e. skipping other positional args)
and also change the usage string to one of the following:
* `$ prog [arg1] [-- <last_arg>]`
* `$ prog [arg1] -- <last_arg>` (if the arg marked `.last(true)` is also marked `.required(true)`)
Closes#888
This makes a very big difference for CLIs that parse a large number of
values (think ripgrep over a large directory).
This commit improved the ripgrep parsing of ~2,000 values, simulating
giving ripgrep a bunch of files. Parsing when from ~1,200,000 ns to
~400,000 ns! This was conducted a i7-5600U 2.6GHz
One can now define default values that contain invalid UTF-8.
The underlying implementation has also been changed to use OsStrs in order to avoid duplication
of code and provide the new APIs basically for free.
Closes#849
Not only does this remove some unsafe code from clap itself, `atty` does the
right thing on Windows too. This isn't relevant now since we don't currently
support colorized output on Windows, but will come in handy if/when we
implement that feature (#836).
* tests: adds tests for default values triggering conditional requirements
* fix: fixes a bug where default values should have triggered a conditional requirement but didnt
Closes#831
* tests: adds tests for missing conditional requirements in usage string of errors
* fix: fixes a bug where conditionally required args werent appearing in errors
* tests: adds tests for completion generators
* tests: adds tests for completions with binaries names that have underscores
* fix: fixes a bug where ZSH completions would panic if the binary name had an underscore in it
Closes#581
* fix: fixes bash completions for commands that have an underscore in the name
Closes#581
* chore: fix the category for crates.io
* docs(Macros): adds a warning about changing values in Cargo.toml not triggering a rebuild automatically
Closes#838
* fix(Completions): fixes a bug where global args weren't included in the generated completion scripts
Closes#841
* fix: fixes a println->debugln typo
* chore: increase version
* fix: fixes a critical bug where subcommand settings were being propogated too far
Closes#832
* imp: adds ArgGroup::multiple to the supported YAML fields for building ArgGroups from YAML
Closes#840
* chore: increase version
Before, inserting a newline did not move the prev_space index forward.
This meant that the next word was measured incorrectly since the
length was measured back to the word before the newly inserted
linebreak.
Fixes#828.
Before, wrapping the help text at, say, 80 characters really meant
that every line could be at most 79 characters wide.
Lines can now be up to and including avail_chars columns wide.
If needed, a desired margin or padding can be subtracted from the
avail_chars argument at a later point.
This fixes#827. The problem was that the check `grp.args.contains(&grp.args[i])` was a) trivially fulfilled (of course `grp.args[i]` is contained in `grp.args`) and b) causing an out-of-bounds error, since the indices were taken from `.required.len()`.
With this change the argument in the group will be removed from the list of required arguments, as intended.
When calling the executable without arguments one expects a help message. However, if even one argument has a default value, the validation step of the parser will always see at least one argument, and therefore report success. This effectively disables the settings.
Specifies that use of a valid [argument] negates [subcomands] being used after. By default
`clap` allows arguments between subcommands such as
`<cmd> [cmd_args] <cmd2> [cmd2_args] <cmd3> [cmd3_args]`. This setting disables that
functionality and says that arguments can only follow the *final* subcommand. For instance
using this setting makes only the following invocations possible:
* `<cmd> <cmd2> <cmd3> [cmd3_args]`
* `<cmd> <cmd2> [cmd2_args]`
* `<cmd> [cmd_args]`
Closes#793
An arg can now be conditionally required (i.e. it's only required if arg
A is used with a value of V).
For example:
```rust
let res = App::new("ri")
.arg(Arg::with_name("cfg")
.required_if("extra", "val")
.takes_value(true)
.long("config"))
.arg(Arg::with_name("extra")
.takes_value(true)
.long("extra"))
.get_matches_from_safe(vec![
"ri", "--extra", "val"
]);
assert!(res.is_err());
assert_eq!(res.unwrap_err().kind, ErrorKind::MissingRequiredArgument);
```
Relates to #764
An arg can now conditionally require additional arguments if it's value matches a specific value.
For example, arg A can state that it only requires arg B if the value X was used with arg A. If any
other value is used with A, arg B isn't required.
Relates to #764
One can now implement conditional default values. I.e. a default value that is only applied in
certain conditions, such as another arg being present, or another arg being present *and*
containing a specific value.
Now it's possible to say, "Only apply this default value if arg X is present" or "Only apply this
value if arg X is present, but also only if arg X's value is equal to Y"
This new method is fully compatible with the current `Arg::default_value`, which gets set only if
the arg wasn't used at runtime *and* none of the specified conditions were met.
Releates to #764
Instead of using Format::Error directly, we need to use a Colorizer to
make sure that the message only gets colorized when it is appropriate
to do so.
Fixes#775
The implementation is basically manually expanded lazy_static! macro
(with some hand-crafted simplifications and inlining), since you can't
use extern crates (and therefore import macros therefrom) in macros.
This ensures that you get this:
p:\Rust\http>target\debug\http -h
http 0.1.0
thecoshman <thecoshman@gmail.com>
nabijaczleweli <nabijaczleweli@gmail.com>
Host These Things Please - a basic HTTP server for hosting a folder fast and simply
Instead of this:
p:\Rust\http>target\debug\http -h
http 0.1.0
thecoshman <thecoshman@gmail.com>:nabijaczleweli <nabijaczleweli@gmail.com>
Host These Things Please - a basic HTTP server for hosting a folder fast and simply
Closes#779
Since ZSH completions use `[ and ]` for descriptions, but clap args use `[ and ]` for possible
values and other auxillary arg information, this was creating a conflict. clap now escapes any
square brackets before writing the help, i.e. `\\[ and \\]` which removes conflicts.
Alternatives would be to switch `[ and ]` for `( and )` but this would create a slight difference
in help messages and completions.
Closes#771
With these options, in case the completion function cannot provide
suggestions, Bash will perform its default completions, based on e.g.
files, directories, and variable names. This is particularly useful for
argument values.
Prior to this commit setting `number_of_values(1)` and `multiple(true)` would cause the help
message alignment to be off. This commit fixes that.
Closes#760
One can now use `Arg::allow_hyphen_values(true)` which will enable `--opt -val` style values only
for the specific arg and not command wide.
Closes#742
Flags, Opts, and Positionals now store their internals using compartmented Base, Valued, and
Switched structs to keep the code duplication down and make it easier to maintain.
Iniside the src/app/parser.rs there have been several changes to make reasoning about the code
easier. Primarily moving related sections out of the large get_matches_with into their own
functions.
Now one can build CLIs that support things like `mv <files>... <target>`
There are a few requirements and caveats;
* The final positional argument (and all positional arguments prior) *must* be required
* Only one positional argument may be `multiple(true)`
* Only the second to last, or last positional argument may be `multiple(true)`
Closes#725
Prior to this commit, conflicting error messages and the suggeseted usage would depend on whether
you defined the conflict on both arguments, or just one, and the order in which you specified the
conflicting arguments at runtime.
Now they are symetrical, meaning the suggestions from the error message are consistent, and it no
longer matters if you specify the conflict in one, or both arguments.
Closes#718
Don't attempt to change the display order of flags/options until any app
settings have been propagated down from a parent App in case DeriveDisplayOrder
and/or UnifiedHelpMessage are propagated.
Fixes#706
One can now use `AppSettings::AllowNegativeNumbers` which functions similar to `AllowLeadingHyphen`
with the exception that only unknown numbers are allowed have a preceding hyphen character.
See the documentation for details and examples.
Closes#696
* Clap has dependencies even with all features disabled.
* The "nightly" feature does nothing, so don't mention it.
* Explain the difference between "unstable" and "nightly" better.
* Split features into groups (default, opt-in, clap-development).
* For contributors: update what tests should be run, and remove make command.
* Removes a repeated word and splits up some long markdown lines.
Also groups features by category and dependencies by feature in Cargo.toml.
The new version of rustc 1.14.0-nightly (144af3e97 2016-10-02) has new
linting warnings/errors. This commit fixes them.
Signed-off-by: Salim Afiune <afiune@chef.io>
Added same alias funtionality for flags, now you can do:
```
Arg::with_name("flg")
.long("flag")
.short("f")
.alias("not_visible_flag")
.visible_alias("awesome_v_flag")
```
Signed-off-by: Salim Afiune <afiune@chef.io>
There are some cases where you need to have an argument to have an
alias, an example could be when you depricate one option in favor of
another one.
Now you are going to be able to alias arguments as follows:
```
Arg::with_name("opt")
.long("opt")
.short("o")
.takes_value(true)
.alias("invisible")
.visible_alias("visible")
```
Closes#669
This should also speeds up the parser (except maybe for short options).
Multi-codepoint characters still can't be used as short options, but people shouldn't non-ASCII options nyway.
Closes#664
Now if one wishes to use value delimiters, they must explicitly set `Arg::use_delimiter(true)` or
`Arg::require_delimiter(true)`. No other methods implicitly set this value.
Closes#666
Previously one could only hide the possible values of an argument application or command wide, and
not on a per argument basis. Now one can use the `Arg::hide_possible_values(bool)` method to hide
only that arguments possible values.
Closes#640
Prior to this change, values were always delimited by default. This was causing issues with code
where the arg had a single value, and contained valid commas and shouldn't be delimited. This
commit changes the rules slightly so that values are not delimited by default, *unless* one of the
methods which implies multiple values was used (max_values, value_names, etc.).
This means single value args should *not* be delimited by default. If one wishes to use the old
way, they can add `Arg::use_delimiter(true)` to such code.
Closes#655
Prior to this commit, clap would mangle help messages with hard newlines
(see #617). After this commit, clap will ignore hard newlines and treat
them like an inserted newline, properly wrapping and aligning text and
then restarting it's count until the next newline should be inserted.
This commit also removes the need for using `{n}` to insert a newline in
help text, now the traditional `\n` can be used. For backwards
compatibility, the `{n}` still works.
Closes#617
In some cases settings were only propogated down one level deep, this
commit ensures settings are propogated down through all subcommands
recursively.
Closes#638
This is useful if a more meaningful message can be displayed to the
user with `Error::exit`. For example, if a file is not found, the
converted `io::Error` will give a message like:
"error: entity not found"
With this, it is possible to replace this message with a more useful
one, like for instance:
"error: configuration file not found"
Coloring is respected. Some duplication in the `From::from` impls was
reduced.
* feat: adds App::with_defaults to automatically use crate_authors! and crate_version! macros
One can now use
```rust
let a = App::with_defaults("My Program");
// same as
let a2 = App::new("My Program")
.version(crate_version!())
.author(crate_authors!());
```
Closes#600
* imp(YAML Errors): vastly improves error messages when using YAML
When errors are made while developing, the panic error messages have
been improved instead of relying on the default panic message which is
extremely unhelpful.
Closes#574
* imp(Completions): uses standard conventions for bash completion files, namely '{bin}.bash-completion'
Closes#567
* imp(Help): automatically moves help text to the next line and wraps when term width is determined to be too small, or help text is too long
Now `clap` will check if it should automatically place long help
messages on the next line after the flag/option. This is determined by
checking to see if the space taken by flag/option plus spaces and values
doesn't leave enough room for the entirety of the help message, with the
single exception of of if the flag/option/spaces/values is less than 25%
of the width.
Closes#597
* tests: updates help tests to new forced new line rules
* fix(Groups): fixes some usage strings that contain both args in groups and ones that conflict with each other
Args that conflict *and* are in a group will now only display in the
group and not in the usage string itself.
Closes#616
* chore: updates dep graph
Closes#633
* chore: clippy run
* style: changes debug header to match other Rust projects
* chore: increase version
Prior to this commit if one wished to use source formatting and ignore
term width they could do `App::set_term_width(usize::MAX)` now one can
also use `App::set_term_width(0)` which does the same thing.
Closes#625
One can now use a list or single value for certain Arg YAML declarations
such as possible_values, etc.
Prior to this commit, if only a single value was desired one would have
to use the format:
```yaml
possible_values:
- value
```
But now once can use
```yaml
possible_values: value
```
Closes#614Closes#613
For example, doing `myprog help subcmd1 subcmd2` would have incorrectly
produced the usage string, `myprog subcmd2 [options]` but now correctly
prints `myprog subcmd1 subcmd2 [options]`
Closes#618
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
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
One can now use more than one meta item, and things like `#[repr(C)]`
Example:
```rust
arg_enum! {
#[repr(C)]
#[derive(Debug)]
pub enum MyEnum {
A=1,
B=2
}
}
```
Closes#543
imp(ArgGroup): Add multiple ArgGroups per Arg
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
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
