Did you check a bit with other command line tool with subcommands what they do ?

The reason why this is so now is that's a message from the program and the current formatting basically follows the gnu convention.

Not necessarily against it but the command name is already mentioned twice just below and your scheme leaves less space for the error message to be seen unwrapped.

Both Git and Nix do not seem to display the name of the command at all. If there is an incomplete subcommand however, Nix will display the subcommand thusfar: e.g. nix profile gives:

$ nix profile
error: 'nix profile' requires a sub-command.
Try 'nix --help' for more information.

however

$ nix profile list -c
error: unrecognised flag '-c'
Try 'nix --help' for more information.

Also

$ git branch -m
fatal: branch name required

So I suppose if we are to write the command name in the error message, then it would make more sense to write the full subcommand.

Thanks for the research @Alizter.

So to sum up git is pretty bad and nix is a bit inconsistent.

I'd like to keep the executable name prefix because it's useful to trace the source of errors in logs or script runs (and follows the gnu convention).

I'm a bit less convinced that it's useful to add the subcommand name since it immediately follows in the sequel. I would tend to favour in making the most of the remaining 80 columns for the error message.

Here's a concrete example that overflows (of course you will always have examples that do, even with the current scheme).

> b0 cmdlet show --h
b0: option '--h' ambiguous and could be either '--hash-fun' or '--help'
Usage: b0 cmdlet show [OPTION]… [CMDLET]…
Try 'b0 cmdlet show --help' or 'b0 --help' for more information.

and

> b0 cmdlet show --h
b0 cmdlet show: option '--h' ambiguous and could be either '--hash-fun' or '--help'
Usage: b0 cmdlet show [OPTION]… [CMDLET]…
Try 'b0 cmdlet show --help' or 'b0 --help' for more information.

It may be a matter of taste but personally I find it easier to get in the first case that there is a problem and that the b0 tool wants my attention.

Namely for me tool: is easier to spot than tool cmd sub: which can be confused with regular program output on a quick scan.

Besides the functions that implement your sub commands are more likely to output errors using the gnu convention (the executable name is easy to reach for, the cmdliner subcommand a little bit less). So always using the program tool name only is likely to be less confusing than having the subcommands only on cli parse errors.

I think I'm gravitating towards a let's not do that…

Hi,
I agree that the overflow is not great, and the full command name is printed just below.
In addition, I thought that this was a change caused by the new Cmd API, but no, cmdliner never printed the term name.
So yeah, let's not do this. Thanks!