Merge branch 'master' into strsim-0.7

This commit is contained in:
Kevin K 2018-01-20 15:26:52 -05:00 committed by GitHub
commit 2a933d1291
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 9 additions and 9 deletions

View file

@ -21,9 +21,9 @@ fn main() {
// so that you know right away an error was made by the developer, not the end user.
//
// # Help and Version
// clap automatically generates a help and version flag for you, unless you specificy your
// clap automatically generates a help and version flag for you, unless you specify your
// own. By default help uses "-h" and "--help", and version uses "-V" and "--version". You can
// safely overide "-V" and "-h" to your own arguments, and "--help" and "--version" will stil
// safely override "-V" and "-h" to your own arguments, and "--help" and "--version" will still
// be automatically generated for you.
let matches = App::new("MyApp")
// All application settings go here...
@ -47,7 +47,7 @@ fn main() {
.required(true)
])
// *Note* the following two examples are convienience methods, if you wish
// *Note* the following two examples are convenience methods, if you wish
// to still get the full configurability of Arg::with_name() and the readability
// of arg_from_usage(), you can instantiate a new Arg with Arg::from_usage() and
// still be able to set all the additional properties, just like Arg::with_name()
@ -79,6 +79,6 @@ fn main() {
// We could continue checking for and using arguments in this manner, such as "license",
// "output", and "interface". Keep in mind that "output" and "interface" are optional, so you
// shouldn't call .unwrap(), instead prefer using an 'if let' expression as we did with
// shouldn't call .unwrap(). Instead, prefer using an 'if let' expression as we did with
// "config"
}

View file

@ -12,8 +12,8 @@ fn main() {
let matches = App::new("MyApp")
// Regular App configuration goes here...
// Assume we an application that accepts an input file via the "-i file"
// or the "--input file" (as wel as "--input=file").
// Assume we have an application that accepts an input file via the "-i file"
// or the "--input file" (as well as "--input=file").
// Below every setting supported by option arguments is discussed.
// NOTE: You DO NOT need to specify each setting, only those which apply
// to your particular case.

View file

@ -822,14 +822,14 @@ impl<'a, 'b> Arg<'a, 'b> {
/// Allows values which start with a leading hyphen (`-`)
///
/// **WARNING**: Take caution when using this setting, combined with [`Arg::multiple(true)`] as
/// it this becomes ambigous `$ prog --arg -- -- val`. All three `--, --, val` will be values
/// **WARNING**: Take caution when using this setting combined with [`Arg::multiple(true)`], as
/// this becomes ambiguous `$ prog --arg -- -- val`. All three `--, --, val` will be values
/// when the user may have thought the second `--` would constitute the normal, "Only
/// positional args follow" idiom. To fix this, consider using [`Arg::number_of_values(1)`]
///
/// **WARNING**: When building your CLIs, consider the effects of allowing leading hyphens and
/// the user passing in a value that matches a valid short. For example `prog -opt -F` where
/// `-F` is supposed to be a value, yet `-F` is *also* a valid short for anther arg. Care should
/// `-F` is supposed to be a value, yet `-F` is *also* a valid short for another arg. Care should
/// should be taken when designing these args. This is compounded by the ability to "stack"
/// short args. I.e. if `-val` is supposed to be a value, but `-v`, `-a`, and `-l` are all valid
/// shorts.