1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
use Serialize;
use ;
/// What to do with a token that looks like a flag but names no declared flag.
///
/// The default is [`UnknownFlags::Value`], which is where this parser parts
/// company with clap, argparse, commander, oclif v2+, and POSIX `getopt` — all of
/// which reject the token. The reason is that those parse *their own* argv, where
/// a dash-word can only be a flag or a typo, while a usage spec is also used to
/// parse things whose flags it does not own:
///
/// - a shell script run through `usage exec`, forwarding options to a tool it wraps
/// - a task's arguments, where the task script is the authority on what it accepts
/// - a completion, asked about a command line that is still being typed
///
/// In all three, a dash-word the spec has not heard of is far more likely to be
/// data in transit than a mistake, and rejecting it would break the wrapper for
/// everyone who did not enumerate the flags of the program behind it.
///
/// The cost is real and worth stating: a misspelled `--hekp` becomes an argument
/// instead of an error, and whether it does depends on whether a positional is
/// free to take it. A CLI that owns all of its flags — as opposed to forwarding
/// them — should say [`UnknownFlags::Error`] and get the stricter reading.
/// The values a spec may use, for error messages.
pub const UNKNOWN_FLAGS_VALUES: &str = "value, error";