Thanks for all the effort put into making Pijul. Much appreciated.

The CLI instructs Please use pijul key to create one However there is no such command:

> $ pijul key
pijul 

USAGE:
    pijul [SUBCOMMAND]

OPTIONS:
    -h, --help
            Print help information

SUBCOMMANDS:
    generate
            Generate a new key. The name used for a key is not required to match a user's remote or
            SSH credentials. By default, new keys are stored in your global configuration directory
    help
            Print this message or the help of the given subcommand(s)
    prove
            Associate a generated key with a remote identity. Patches authored by unproven keys will
            only display the key as the author. Example of proving a key (after generating one):
            `pijul key prove <nestlogin>@ssh.pijul.com`

pijul generate
No such subcommand: "generate"

I believe the help should be (** added ):

> $ pijul key
pijul **key**

USAGE:
    pijul **key** [SUBCOMMAND]

I believe the above change solves this issue. The current output is:

$ pijul key
pijul-key 
Key generation and management

USAGE:
    pijul key <SUBCOMMAND>

OPTIONS:
    -h, --help    Print help information

SUBCOMMANDS:
    generate    Generate a new key. The name used for a key is not required to match a user's
                    remote or SSH credentials. By default, new keys are stored in your global
                    configuration directory
    help        Print this message or the help of the given subcommand(s)
    prove       Associate a generated key with a remote identity. Patches authored by unproven
                    keys will only display the key as the author. Example of proving a key (after
                    generating one): `pijul key prove <nestlogin>@ssh.pijul.com`

A note: the old code was doing Self::command().write_long_help(&mut std::io::stdout())?;, which was wrong in two ways:

1. It was not including the subcommand context (this bug report). Simply leaving the validation up to clap itself results in correct output with the subcommand context, as shown above.
2. It would never produce colored output, because it was using write_long_help instead of print_long_help. This is only relevant in case the above change is not satisfactory, as we should make sure to support colored output where possible, and write_long_help(stdout) is an antipattern from that perspective.

Hi @chevyparakeet! First, thanks for this patch, because it triggered a bug in unrecord. The reason is a bit sad though, it is because the file this patch changes doesn’t exist anymore. However, the issue has been fixed in the meantime.

Thanks again!