Live data from Hacker News

CLI Guidelines – A guide to help you write better command-line programs

clig.dev

11–20 of 217 posts

Re: CLI Guidelines – A guide to help you write better command-line programs

#11
post #10
post #7

Earlier quoted context omitted.

Yea, like, imagine if posix pipes and command-line flags could be typed.

Powershell offers this I believe.

Yep. Not perfect... type systems have come a long way since PowerShell did it. But it's a good start.

Look at stuff like PowerShell secure strings for an example of the sort of neat stuff you can do.

Re: CLI Guidelines – A guide to help you write better command-line programs

#12
Hah. This is a topic that's dear to my heart and have blogged occasionally about it... but never in such a comprehensive form. Great job! Now... I gotta read through everything.

But... here is a series of blog posts in which I covered similar themes years ago: https://jmmv.dev/series.html#CLI%20design

And here is another single post that touches upon a single guideline I came across while skimming through the text: https://jmmv.dev/2020/08/config-files-vs-directories.html . It might be helpful in providing more details about the _whys_ behind each guideline.

Lastly, I'll also mention the "Producing open source software" book by Karl Fogel, which provides a lot of useful advice too, especially on how to ship the tools: https://producingoss.com/

Re: CLI Guidelines – A guide to help you write better command-line programs

#13
post #8
post #2

Hello HN! We’re Ben, Aanand, Carl, Eva, and Mark, and we made the Command Line Interface Guidelines. Earlier this year, I was working on the Replicate CLI [0]. I had previously worked on Docker so I had a bunch of accumulated knowledge about what makes a good CLI, but I wanted to make Replicate really good, so I looked for some design guides or best practices. Turns out, nothing substantial had been published since t…

Since you bring up Docker, this little behavior has always baffled me: $ docker image ls -h Flag shorthand -h has been deprecated, please use --help But: $ docker image -h ls Flag shorthand -h has been deprecated, please use --help Flag shorthand -h has been deprecated, please use --help Flag shorthand -h has been deprecated, please use --help What's up with that? I'm guessing cobra nonsense, because everyone ends up…

Looks like it wants you to type --help, not -h.

Still weird though, since -h is indeed a very very common shorthand used in many commands.

Re: CLI Guidelines – A guide to help you write better command-line programs

#14
post #6

It's kind of crazy that we still don't have a standard computer readable way for a program to describe it's argument structure in a computer readable way that could be used for command line autocomplete. E.g. something like an extra section in the binary that describes how arguments are processed.

http://docopt.org/

Re: CLI Guidelines – A guide to help you write better command-line programs

#16
This is a great resource, thanks for the effort.

I strongly disagree with the “ Don’t bother with man pages” advice. It’s extremely annoying when tools don’t provide a manpage. The overhead of opening up a browser to reference command is cumbersome and highly annoying.

There are tools such as pandoc that make generating manpages from various source formats very easy.

Perhaps it is just my grouchy old man syndrome…

Re: CLI Guidelines – A guide to help you write better command-line programs

#17
post #10
post #7

Earlier quoted context omitted.

Yea, like, imagine if posix pipes and command-line flags could be typed.

Powershell offers this I believe.

NuShell is also attempting this. Both are cross platform.

https://github.com/nushell/nushell

Re: CLI Guidelines – A guide to help you write better command-line programs

#18
post #16

This is a great resource, thanks for the effort. I strongly disagree with the “ Don’t bother with man pages” advice. It’s extremely annoying when tools don’t provide a manpage. The overhead of opening up a browser to reference command is cumbersome and highly annoying. There are tools such as pandoc that make generating manpages from various source formats very easy. Perhaps it is just my grouchy old man syndrome…

They're not saying you shouldn't provide command-line help. Just that you should deliver them through a `help` subcommand and/or through a `--help` flag (like `git` does) because people don't find man pages and because man pages don't work on every platform.

Re: CLI Guidelines – A guide to help you write better command-line programs

#19
post #16

This is a great resource, thanks for the effort. I strongly disagree with the “ Don’t bother with man pages” advice. It’s extremely annoying when tools don’t provide a manpage. The overhead of opening up a browser to reference command is cumbersome and highly annoying. There are tools such as pandoc that make generating manpages from various source formats very easy. Perhaps it is just my grouchy old man syndrome…

Maybe I'm suffering from similar syndrome, but I'm under 30 in human Earth years. However, I very much agree with you and would take it a step further to say that programmatically opening the browser with the help flag is also very unwelcome (I'm looking at you, git >.> )

Re: CLI Guidelines – A guide to help you write better command-line programs

#20
post #18
post #16

This is a great resource, thanks for the effort. I strongly disagree with the “ Don’t bother with man pages” advice. It’s extremely annoying when tools don’t provide a manpage. The overhead of opening up a browser to reference command is cumbersome and highly annoying. There are tools such as pandoc that make generating manpages from various source formats very easy. Perhaps it is just my grouchy old man syndrome…

They're not saying you shouldn't provide command-line help. Just that you should deliver them through a `help` subcommand and/or through a `--help` flag (like `git` does) because people don't find man pages and because man pages don't work on every platform.

Right. I still prefer terse help text from the command line, and more in-depth in the man pages.

I find commands with copious -h output and having to pipe that into a pager or using scroll back a far worse UX than just opening up a man page that’s easily searchable / scrollable.

Post reply on HN