Do we want clap's context-aware usage strings or our custom usage strings?

[miDeb]

It looks like all utilities specify their own usage string. For example, sort:

fn get_usage() -> String {
    format!(
        "{0} [OPTION]... [FILE]...
Write the sorted concatenation of all FILE(s) to standard output.
Mandatory arguments for long options are mandatory for short options too.
With no FILE, or when FILE is -, read standard input.",
        NAME
    )
}

Quoting clap's documentation of usage():

CAUTION: Using this setting disables claps "context-aware" usage strings. After this setting is set, this will be the only usage string displayed to the user!

This means that when you give the wrong argument (let's say you write sort -o x -o y), you don't get a usage string about the misused flag (USAGE: sort --output <FILENAME>), but you always get our custom usage string.

I quite like the context-aware usage strings, and I wondered if we could not specify our own usage strings but let clap generate them instead in all cases. In the help output they'd look a bit different (sort [FLAGS] [OPTIONS] [--] [files]..., or sort [OPTIONS] [--] [files]... if we enable UnifiedHelpMessage).

Thoughts?

[rivy]

I like it in principle (although I'd like to see some actual messaging); it would be less code for an added feature (win-win).

But I don't think clap will support correct usage strings for busybox-type executables (eg, clap will display USAGE: sort ... instead of USAGE: coreutils sort ... when using coreutils sort ...). If we could get the usage to display a correct executable string, I'd be, tentatively, for the change.

[miDeb]

We can get clap to display the correct usage string by explicitly setting the binary name by using bin_name().

[rivy]

I've pushed a new version of #2471 which incorporates the changes I was making. Once that's merged, we can take a look at this change fairly easily using the execution_phrase!() macro in that PR.

[Funky185540]

A bit late here, but I'm in favor of having clap generate the usage messages. I particularly like that it groups arguments into flags (true/false by mere presence) and options (with arbitrary arguments) in the help text. This grouping is also included in the usage strings, which fits imo. It's trivial, but I like it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.