Hacker News Reader

Comment by zelly | Hacker News Reader

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 dangerous commands

- separate the interface into a tree of subcommands (Go/Docker/AWS style) rather than a flat assortment of flags

- if you are displaying tabular data, present an ncurses interface

- (extremely important) shell completion for bash and zsh

View on HN

No, please don't use escape codes in your output. Use the library that is designed for this purpose: terminfo.

Explicit escape codes is problematic when using any terminal that isnt' fully compatible with the xterm control codes, and doesn't allow me to turn those codes off by setting TERM to dumb.

Far too many times have I redirected output from a program to a file only be be bombarded with escape codes, breaking grep and other tools that process the output.

Not to mention the fact that using terminfo is much easier than manually outputting the control codes.

> Not to mention the fact that using terminfo is much easier than manually outputting the control codes.

Strong disagree. I already know many control codes by heart and can write them inside the printf strings. For terminfo, I have to include it, link against it, call bizarre functions, and then the library must be available at compile time, at runtime, and also the shared files at runtime. I have seen each one of these constraints fail for different reasons, and now I simply ignore the existence of terminfo. It is better to not abuse color, make color optional, but if you need some color you just use the xterm control codes that work everywhere.

No, don't bother with terminfo. It just gives you support for terminals that haven't been in use since the Apollo program. Nowadays it's perfectly fine to use ANSI escapes directly, which are, after all, a standard.

At the very least, use isatty() to check whether the output is actually to a terminal before polluting the log files.

isatty and checking for TERM=dumb are sensible (as well as flags to enable/disable colors). Terminfo however is a meh depencency and since common tools (e.g. git) don't bother either there is no point in anything beyond that.

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.

Yes, Please, no emojis.

git’s behavior is really nice: any program on $PATH named `git-foo` can be accessed as a sub command `git foo`. I’ve personally taken this a step further, and wrapped git in a shell function so that `git cd bar` navigates to the directory `bar` relative to the repository root.

> - 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 multiplexer etc. I'm probably not going to use it.

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 :)

Being part of Unicode does not preclude having to install additional fonts.

I merely mentioned fontawesome as one of many possible examples. And as already said, a symbol having its place in unicode does not mean it is available on the computer or in a certain program. For example, in Linux terminals it's not uncommon that at least one optional font installation is required in order to get various emoji to display correctly, let alone other non-western symbols.

Many people use the terminal exactly because it displays fewer kinds of content than e.g. a web browser, which as a side effect simplifies many situations.

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. I tried to paste the example output from yubikey-agent into my terminal, and all I got was a bunch of differently sized squares. Very informative...

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).

My terminal has been configured to use UTF-8 for nearly twenty years. Apparently I do not have any font with these glyphs installed though, and I don't think it's reasonable to expect that people do.

Not all terminals support emojis. AFAIR, xterm doesn’t. I was stuck on xterm at my last job (only terminal that really worked on that system). Emojis are for SMS, and that should be it. Use emoticons.

It's not portable. It looks really bad on a terminal emulator that does not support emojis (at least half of the ones out there esp on Linux). There are dozens of emoji fonts which all look different. You never know what your user is going to see. If your users are only using macOS and Terminal.app, then it may not be so bad, but if you are building a command line application, then I should be able to use it from a text-only console on an old system, VM, or embedded device. Don't assume all your users are going to be using it from a Macbook Pro or Ubuntu.

- Don't emit colour unless asked.

- Don't assume the user's terminal's background colour. Pragmatically, you can use red; the rest are too light or too dark.

Or just don't use a terminal color scheme where the any foreground color except 30 has bad contrast with color 40 and don't use a default background color that has worse contrast than 40 with all foregreound colors other than 30.

And Fish!

Reply on news.ycombinator.com