You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing the same with bpaf, does not catch any bad arguments:
use bpaf::*;#[allow(dead_code)]#[derive(Debug,Bpaf)]#[bpaf(options, version)]pubstructOptions{/// Message to print in a big friendly letters#[bpaf(positional("MESSAGE"))]message:String,}fnmain(){println!("{:?}", options().run())}
cargo run -- --badarg --version
Version:0.1.0
The text was updated successfully, but these errors were encountered:
Behavior for --help is partially intentional, behavior for --version is mostly because it uses the same mechanism as --help.
Main motivation for --help is often I find myself wondering "how do I use this again?" for apps that don't have shell completion. With this behavior I simply slap --help at the end and get the info, without it this means getting the command line to a state here it can be parsed, checking help and then restoring the original.
This behavior is not unique either: cargo (clap?) is undecided if it supports invalid arguments along with help or not: cargo --help --nosuch works, cargo --nosuch --help fails to work. ghc (Haskell compiler) works either way, gcc complains about invalid argument but produces help message anyway.
I'll fix the --verbose behavior when I'm around it since there's no reason to accept invalid names along with it. Any particular reason you want the same behavior for help?
Most unix utilities require valid arguments passed to them, even in the presence of
--help
or--version
, e.g. git:Doing the same with bpaf, does not catch any bad arguments:
The text was updated successfully, but these errors were encountered: