It would be nice if you could specify a default subcommand, like systemctl does with list-units. It could look like this:
#[derive(StructOpt)]
#[structopt(name = "systemctl", default_cmd = "list-units")]
enum Systemctl {
#[structopt(name = "list-units")]
ListUnits {},
#[structopt(name = "status")]
Status {},
}
I don't get the feature.
You can have an optional subcommand:
#[macro_use] extern crate structopt;
use structopt::StructOpt;
#[derive(StructOpt, Debug)]
struct Opt {
#[structopt(subcommand)]
subcommand: Option<Cmd>
}
#[derive(StructOpt, Debug)]
enum Cmd {
#[structopt(name = "list-units")]
ListUnits,
#[structopt(name = "status")]
Status,
}
fn main() {
let opt = Opt::from_args();
println!("{:?}", opt);
}
Having a "default subcommand" is quite complicated: you need something to create a default variant. I need a real case example to understand the need.
@bb010g ping
I'd simply like to be able to nicely have a default command, like you can have defaults for values. You could argue that default_value doesn't need to exist because you can just use an Option<T> and create the default with a function or at use, but it's convenient to specify the default right there. I'm not sure what you'd want to help clarify.
If you type cmd -a -f the flags a and f should go to the subcommand ?
That would be an issue. It looks like systemctl doesn't really have any subcommand-specific flags, which probably helps them get away with this. I'd lean towards prioritizing main command options first, and then subcommands if that fails, but that would introduce a new level of complexity to parsing. So yeah, with that in mind, explicitly using an Option<Cmd> and forcing the library user to think about how they want to handle default subcommand options would probably be the best choice, unless you or anyone else can think of a better solution. (It might not hurt to add a note on this to the docs on why there's not a default subcommand feature, and what you'd need to watch out for if you want to roll your own.)
I don't have any great idea about that.
Now, with the context, it should be a feature request to clap that parse the command line, not structopt.
Is there an issue or resolution to this in clap?
I can't find anything with a quick search
The feature request on clap is clap-rs/clap#975 but it has also been closed...