State of the CLI
Unlike most computer interfaces, the Command Line Interface (or CLI) hasn’t changed much over the last 30 years. Does this mean we’re in a good place?
Tue, 29 Jan 2013
Pros and cons
The CLI can be helpful in a lot of cases, but it has a bit of a learning curve. It allows you to do simple canonical things, but these things can be linked together in various ways that can’t often be done with Graphical User Interfaces (or GUIs). Thus sparing you from tedious repetitive labour.
Some applications also allow for command line interaction next to their graphical user interface, which makes them able to be integrated in automated processes.
In my opinion, the CLI sits about half way between raw programming and using a graphical application to get your tasks done. There are graphical applications that can give you a lot of control as well. A good example of this is OS X’s Automator.
It may be that your product provides (or requires) some interaction on the CLI level. Now how do you go about doing this right?
GNU and BSD
Linux distributions are a mixed bag of different programs, and so these programs don’t always behave in the same predictable ways. Most common commands originate either from the GNU or BSD projects.
Superficially, BSD sticks more to the older Unix days, whilst GNU tries to come up with new ideas that makes their programs a little more convenient to use.
Eric Raymond’s The Art of UNIX programming goes into CLI interface design a little bit. The GNU Coding Standards has something to say about the topic as well.
Overall, documentation and guidelines are sparse. As a developer writing software for Linux distributions, it’s not clear where one should go.
The CLI is used most often by people that are more familiar with computers, software developers, system administrators, and those who like to tinker. This doesn’t mean that the CLI has to or is allowed be a suboptimal experience on that level.
What’s noticeable is that there doesn’t seem to be much documented reasoning or motivation behind any of the CLI design decisions. Things mostly seem the way they are because of “historic” reasons or tradition.
The next couple of months I’m going to to assess the CLI of various common software packages and write blog posts about them, to come up with a list of best practises that doesn’t conflict with the current state of utilities out there.
I’d like to explicitly mention that these will be best practises that are compatible with current conventions, not some new official “standard”. Having some rules that you can keep in mind, as well as knowing the reasons behind them. I don’t want to fall into the standards trap.
The usual suspects
If you administrate a server, you’ve probably used commands from the following packages:
- GNU coreutils, a collection of basic tools, such as cat, ls, and rm
- GnuPG, encryption tools
- openSSH, connectivity tools for remote access
- Apt, package management
- Git, source code management
- cURL, data transfer/download tool
These are some of the tools I’ll be looking at.
To wrap up: this is not about redefining the command line experience, or creating some revolutionary alternative. rather to identify issues, streamline the process, and come up with some design patterns that may help you write a usable CLI application for Linux.
If you have any CLI pet peeves, know of commands that are really good/bad, or have any other tips or links you think I should read, please let me know.
Comments? Send me a tweet.