Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I want -h -help --help and -? to all print the usage text. The fact that so many CLI tool programmers either don't realize that this is the right thing to do, or don't bother to do it, is just part and parcel of how user-hostile most programmers are.


I’m against lowercase -h for help (pretty common, but not universal, like in -h for human-readable sizes in GNU coreutils) for the same reason as lowercase -v for version (very rare, uppercase -V is more frequent, but the Lua interpreter does use lowercase): it hogs a valuable mnemonic for a case that doesn’t really need to allow for muscle memory to develop (the best motivation and use case for short options IMO): if you are reaching for help or the version number, you’re likely already out of the flow and are actively thinking about what you’re typing, and these options don’t need to combine with others anyway.

Allowing -? would be nice, even if only to make life easier for recent DOS/Windows expatriates, but for C programs there’s an unfortunate historical accident making this awkward: POSIX getopt(3) returns the next option character on success and a question mark on error. No reason it couldn’t return something else in principle, but realistically it’s not going to change at this point in history.


Needing to get info on command line flags is not only such a common thing but also a kind of recursive problem (you can't find out what flag to pass without being able to invoke the help text in the first place) that I'd argue it's the most valuable possible recipient of a single letter mnemonic. Having a universal and short way to print out the list of options seems way more beneficial than something like human-readables sizes, which only even makes sense for a certain subset of command line tools (what would it mean to invoke `python` or `docker` with a request for "human-readable sizes?).


> you can't find out what flag to pass without being able to invoke the help text in the first place

  man command
*ducks*

Seriously, though, man pages are not perfect (among other things because they only work as a quick reference for commands with a small amount of knobs), but I do think that the tension you are referring to is best resolved by accessing the option reference through an out-of-band mechanism (even if it is actually stored in-band, such as when using the ancient ident(1) to retreive version strings).

> what would it mean to invoke `python` or `docker` with a request for "human-readable sizes"?

I will not deny my desire for a common glossary of short options (see the train wreck that is the SysV / GNU coreutils delimited-text suite), but at the same time I don't think it's realistic for every option letter to have a single meaning throughout the whole of the system, which is how you seem to have interpreted my statement. I do think that being able to type -h instead of --help is less valuable than being able to not use a contrived second-choice letter for something else that really wants to be called -h.


Funnily enough, I commented elsewhere shortly after the one you responded to about man commands versus help text: https://news.ycombinator.com/item?id=30999162

I won't bother restating the whole thing here, but basically, having a giant wall of text dumped into a pager is not super ergonomic if you just want to look at a couple examples while typing. Man pages are definitely useful, but for a different type of thing.


If commands print out their help message, or even just tell you how to print out the help message, when given a bad flag, then you can use:

  foo --$(uuid)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: