mirror of
https://github.com/clap-rs/clap
synced 2024-12-14 23:02:31 +00:00
7a59dc3da4
This reverts commit 6898fbde33.
PR #2144 added the `license` field but no consumer has been added since
the (like Issue #1768). Since this is not ready yet, I am pulling it
from the 3.0 release.
So far, our main route for pulling a feature from the release has
been to put it behind a `unstable-*` feature flag and to create a
stablization tracking issue. I chose to instead remove the feature
because a write-only field with no effect does not provide values for
people to use in as an early access and so doesn't outweight the cost of
the extra documentation noise and code noise it creates. Additionally,
keeping an `unstable-` feature around when it has such an unknown path
(and time table) to stalbization feels like it violates YAGNI. I'm
uncertain how much of this feature we can implement and not create a
legal trap for users because the crate's license is insufficient for the
final artifact's license. I feel our stabliazation process sshould be
about iteration and collecting user feedback which this doesn't line up
with.
When someone is ready to tackle #1768, it will be easy to revert this
commit and pick up the work again.
Fixes #3001
57 lines
2.4 KiB
Rust
57 lines
2.4 KiB
Rust
use clap::{App, Arg};
|
|
|
|
fn main() {
|
|
// Subcommands function exactly like sub-Apps, because that's exactly what they are. Each
|
|
// instance of a Subcommand can have its own version, author(s), Args, and even its own
|
|
// subcommands.
|
|
//
|
|
// # Help and Version
|
|
// Just like Apps, each subcommand will get its own "help" and "version" flags automatically
|
|
// generated. Also, like Apps, you can override "-V" or "-h" safely and still get "--help" and
|
|
// "--version" auto generated.
|
|
//
|
|
// NOTE: If you specify a subcommand for your App, clap will also autogenerate a "help"
|
|
// subcommand along with "-h" and "--help" (applies to sub-subcommands as well).
|
|
//
|
|
// Just like arg() and args(), subcommands can be specified one at a time via subcommand() or
|
|
// multiple ones at once with a Vec<App> provided to subcommands().
|
|
let matches = App::new("MyApp")
|
|
// Normal App and Arg configuration goes here...
|
|
// In the following example assume we wanted an application which
|
|
// supported an "add" subcommand, this "add" subcommand also took
|
|
// one positional argument of a file to add:
|
|
.subcommand(
|
|
App::new("add") // The name we call argument with
|
|
.about("Adds files to myapp") // The message displayed in "myapp -h"
|
|
// or "myapp help"
|
|
.version("0.1") // Subcommands can have independent version
|
|
.author("Kevin K.") // And authors
|
|
.arg(
|
|
Arg::new("input") // And their own arguments
|
|
.about("the file to add")
|
|
.index(1)
|
|
.required(true),
|
|
),
|
|
)
|
|
.get_matches();
|
|
|
|
// You can check if a subcommand was used like normal
|
|
if matches.is_present("add") {
|
|
println!("'myapp add' was run.");
|
|
}
|
|
|
|
// You can get the independent subcommand matches (which function exactly like App matches)
|
|
if let Some(matches) = matches.subcommand_matches("add") {
|
|
// Safe to use unwrap() because of the required() option
|
|
println!("Adding file: {}", matches.value_of("input").unwrap());
|
|
}
|
|
|
|
// You can also match on a subcommand's name
|
|
match matches.subcommand_name() {
|
|
Some("add") => println!("'myapp add' was used"),
|
|
None => println!("No subcommand was used"),
|
|
_ => println!("Some other subcommand was used"),
|
|
}
|
|
|
|
// Continued program logic goes here...
|
|
}
|