Live data from Hacker News

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

clig.dev

161–170 of 217 posts

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

#162

WRT man pages: > and they don’t work on Windows My cygwin install says otherwise. And even if that were not the case I wouldn't not do something useful because of a deficiency in a particular platform. We have enough issues with that via needing to support IE11 still in the day job! Include the man page on the other documentation. You probably already have it written and can convert it from other docs so it might be…

That, or MSYS2.

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

#163
post #69

My advice as a user of CLI: - no emojis please, ever - if you want to make it look nice, use ANSI escape codes for color rather than emojis. even then, don't use color alone to convey meaning because it will most likely get destroyed by whatever you're piping it to. - please take the time to write detailed man pages, not just a "--help" screen - implement "did you mean?" for typos (git style) and potentially dangerou…

I like emojis quite a bit, and I suspect many other people do to. I'd be sad if the CLI tools I use today stopped outputting them, and I feel their output would lose a lot of clarity.

Many people are more visually oriented, and are greatly aided by images and color. A standard `NO_EMOJIS` environment variable could perhaps be used to help both camps, just like `NO_COLOR` is available today.

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

#164
post #4

Why are the font sizes so huge? The computed font size is 30px, compared to 12px for hn.

Also the font size is hardcoded so zooming in does nothing other than making scrolling terrible

It works for me. I can decrease the font size the usual way.

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

#165

Yes. Please ditch the man pages and instead get out of the terminal and get tracked in the browser. Like this website which needs Google ad tracking.

Yeah. The direction we are taking is nuts. Is it because of incompetent web developers? For everybody: do not take it personally.

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

#167
post #120
post #105

Earlier quoted context omitted.

> - no emojis please, ever Why not? Do you also don't want to see icons in GUIs?

Personally, I don't. I quite like things to be text, because text can be understood . Icons can be... learned , I suppose, but then they tend to be inconsistent between apps and even change depending on themes and whatnot - so in general, it's mostly like playing a game of Memory where someone keeps shuffling the pieces. But the main reason not to use emojis would be that you have no idea how they'll look to the user…

You should try to configure your terminal to use UTF-8.

Symbols are universally used for quickly warning/informing in the real world and if done well, are very intuitive. Ignoring them in the digital world would be going against human UX (but no one ignores them, of course, even very old CLis already used them, but with the widespread use of UTF-8 and Emojis with that, it just became much easier and better).

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

#168
post #105

Earlier quoted context omitted.

> - no emojis please, ever Why not? Do you also don't want to see icons in GUIs?

Icons in GUIs are commonly used for interactive elements. Most CLI tools are not interactive, they just produce some output and the user expects that output to be easy to parse and compatible with as many terminals as possible. You can easily output tables, bullet lists and many other things just with basic symbols supported everywhere. If your CLI program requires installing fontawesome or breaks in a terminal multi…

Emojis are part of unicode. No need for font awesome to support emojis.

Visit https://emojipedia.org and notice how all emojis have their own code point :)

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

#169
post #40
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…

Absolutely - I can't buy into the "don't write man pages" idea. For many years I've had this function in my RC files for macOS: pman() { man -t "$@" | open -f -a Preview; } It opens the given man page in Preview, typeset beautifully. No such thing is available for random text printed to the console, nor is a console pager (as recommended by this article) an acceptable substitute for this.

For those on Linux you can do this with:

f=$(mktemp);man -t "$@" > "$f" && ( {some-pdf-viewer} "$f" ; rm "$f" )

... replacing '{some-pdf-viewer}' with whatever PDF viewer works for you. There is probably one that will take the document on stdin, but I am not aware of one.

I realize I'm late to the party here, but thought is was worth posting anyway. (edited for typo)

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

#170
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…

Most of what you say is useful common sense, but the bit about not bothering with manpages is plain evil. If anything, the man page must be written before the program interface!

Is there a usage statistic for how often man pages are read? I violently agreed with the article here. There are zero times I wouldn’t rather switch to a browser. Even if I had to dig up my phone from my pocket and search for help there, I’d much rather do that.

Also, more and more tools are cross platform and man pages aren’t a thing on windows (are they?).

Post reply on HN