CLI Guidelines – A guide to help you write better command-line programs
161–170 of 217 posts
Re: CLI Guidelines – A guide to help you write better command-line programs
#162WRT 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…
Re: CLI Guidelines – A guide to help you write better command-line programs
#163My 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…
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
#164Re: CLI Guidelines – A guide to help you write better command-line programs
#165Yes. 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.
Re: CLI Guidelines – A guide to help you write better command-line programs
#166Re: CLI Guidelines – A guide to help you write better command-line programs
#167Earlier 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…
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
#168Earlier 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…
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
#169This 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.
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
#170Hello 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!
Also, more and more tools are cross platform and man pages aren’t a thing on windows (are they?).