I don't think -h is actually that common. For instance, the GNU commands don't seem to support it. (Some of them use it as a shortcut for --human-readable, which might be useful for commands like nix path-info --closure-size). We have to be careful about introducing global one-character flags since it's a pretty limited namespace.

I don't think -h is actually that common. For instance, the GNU commands don't seem to support it.

OTOH a lot of other devtools (e.g. python3, cargo, node and so on) use -h.

(Some of them use it as a shortcut for --human-readable, which might be useful for commands like nix path-info --closure-size). We have to be careful about introducing global one-character flags since it's a pretty limited namespace.

Ah right, missed that one. But -h for all commands seems to be a far more common use-case to me. Is there any reason not to use -H for --human-readable there? I mean, the nix-command is marked as experimental anyways and thus subject to change.

ping @edolstra any updates on this?

There are other tools such as GNU coreutils and git that only accept --help so -h is not universal. Since the nix cli is a command dispatcher, it's probably best to keep the single-char flags for the target commands.

yeah but it's becoming more and more common which is why I personally think that this is an actual (though small) improvement. However, if I'm in a minority here, I'll close this :)

I don't think -h is actually that common. For instance, the GNU commands don't seem to support it.

GNU recommends to use the long version while the short version is used in UNIX.

Please define long-named options that are equivalent to the single-letter Unix-style options. We hope to make GNU more user friendly this way.

https://softwareengineering.stackexchange.com/a/307472/193427
https://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

I provide both when possible. At least often used parameters should have a short version.

I very frequently use nix path-info -rhsS | sort -hk3 to see a closure, and the cmdline consistency with all the common coreutils tools is nice!

Closing for now. While I like -h as shorthand for --help, it seems as there are a lot of folks against this, also we'd already have to change e.g. the nix path-info arg (and work around even more conflicts in the future).

There are other tools such as GNU coreutils and git that only accept --help so -h is not universal. Since the nix cli is a command dispatcher, it's probably best to keep the single-char flags for the target commands.

It's true that git -h doesn't exist, but git <command> -h does show an abbreviated version of git <command> --help, which I find rather helpful.

There is however something that could be improved without adding additional flags:
Here's a small case-study:

$ git mv       
usage: git mv [<options>] <source>... <destination>

    -v, --verbose         be verbose
    -n, --dry-run         dry run
    -f, --force           force move/rename even if target exists
    -k                    skip move/rename errors
$ git mv --garbage-flag
error: unknown option `garbage-flag'
usage: git mv [<options>] <source>... <destination>

    -v, --verbose         be verbose
    -n, --dry-run         dry run
    -f, --force           force move/rename even if target exists
    -k                    skip move/rename errors
$ nix why-depends       
error: more arguments are required
Try 'nix --help' for more information.
$ nix why-depends --garbage-flag
error: unrecognised flag '--garbage-flag'
Try 'nix --help' for more information.

• git will show an abbreviated version of the --help command for an invalid invocation where nix just points to nix --help
• nix does point to nix --help even though nix why-depends --help would be what I'm searching for.

So showing the usage on an incorrect invocation could get rid of the need for -h.