Hello there! I'm Hylke Bons and
I design pretty and usable digital things
about — — @hbons


People who haven’t met me in person sometimes wonder if this is a guy’s or a girl’s name. It can be used for either, but I’m a guy. Originally I’m from The Netherlands (but partly of Asian blood). More specifically the northern city of Groningen. There I studied Information Science at the local university.

At the moment I live in London, England, where I work as an Interaction and Graphic Designer at Red Hat’s User Experience team. I like creating (digital) things that aim to make people’s lives easier, and make these things look pretty at the same time. I try to document my experiences in these areas in the Journal section of this site. Right now, SparkleShare and GNOME get most of my attention, but you may know me from my earlier icon work on Pidgin and MeeGo.

In my free time I like to do fun things (surprise!), like doing photography, playing games, and cycling on my trusty Brompton. I like to travel to places to just wander around and see the world, although I should do that more often.

I take design jobs for food, simply send me an email. You can also find me on Twitter, Flickr and Github. If you are in need of an illustrator, consider hiring my sister (because she's awesome).

home   »   journal

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?


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.

Best practises

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.