#command line

Command-line interfaces, a.k.a. shells / 5 posts

Newsletter
  • Get a newsletter digest every Friday:
Contact

Send me feedback, tips, bug reports, and anything else:

About me and the blog

My name is Marcin Wichary. I’ve worked as a UX designer, typographer, front-end person, and manager at Google, Medium, and Figma. I’ve also written a book about keyboards and typing, gave talks, and published essays about design, typography, and technology.

Unsung is my blog about software craft and quality.

More info about Unsung

Send me feedback, tips, bug reports, and anything else:

More info about Unsung

“Tuned to the particular typing mistakes to which Teitelman was prone”

Recently, I asked on social media, “Is there a UX design equivalent to this?”, and attached this photo:

In case you don’t know, this is a (mythical) male-to-male power extender. Requests for those seem to spike around Christmas, and the reason is this: if you put up your lights, chain them together, and only then realize you did it in the wrong order – with the holes next to a socket – it seems much easier to imagine using this cable than reversing all the lights.

There are apparently other uses, like powering your whole house from a portable generator. But I don’t know if you can actually buy such a cable. What I do know is why you wouldn’t want to buy one. The cable has a horrible flaw that might not be immediately obvious: once you plug it in, the other end now has exposed live wires that can electrocute someone.

So, my question was really: What in design has a similar property? What’s something that seems like a good idea, but is actually pretty bad and/or even dangerous?

I would be curious if you have any nominations, but I got two answers that seem interesting enough to share.


The first one comes to us from the (also mythical) Jargon File, in an entry for DWIM:

DWIM [acronym: Do What I Mean]

Warren Teitelman originally wrote DWIM to fix his typos and spelling errors, so it was somewhat idiosyncratic to his style, and would often make hash of anyone else’s typos if they were stylistically different. Some victims of DWIM thus claimed that the acronym stood for ‘Damn Warren’s Infernal Machine!’.

In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another [user] there typed delete *$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren’t any editor backup files, so DWIM helpfully reported *$ not found, assuming you meant 'delete *'. It then started to delete all the files on the disk! The [user] managed to stop it with a Vulcan nerve pinch [Ctrl-Alt-Del] after only a half dozen or so files were lost. […]

DWIM is often suggested in jest as a desired feature for a complex program; it is also occasionally described as the single instruction the ideal computer would have.

I have a complicated relationship with the Jargon File – a collection of computing anecdotes from the 1970s – and I don’t know if I fully trust it, but I liked this story and Wikipedia has a bit more about it:

Teitelman’s DWIM package “corrected errors automatically or with minor user intervention”, similarly to autocorrection for natural language. […] Critics of DWIM argued that it was “tuned to the particular typing mistakes to which Teitelman was prone, and no others” and called it “Do What Teitelman Means” […]

If this rings bells, it’s because we talked about a similar idea before vis-à-vis Postel’s Law.


The second answer was a property of the desktop trashcan on Windows or a Mac, and this one I could’ve thought of myself, because in 2020, I wrote about it in my book’s newsletter.

To spoil the story: any onscreen trashcan that has a bulging/​filled/gross appearance whenever there are files inside will prompt some percentage of users to clean it just to restore its pristine appearance… in the process nullifying its utility and purpose.

Like the original power extender, the second visual state of the trash seems like a useful thing to offer to the users, but it comes with a possibly regrettable price. This is what connects the two stories – both talk about “nice,” but underbaked improvements leading to potentially losing files.

Oh, you say, all of onscreen trashcans do that? Well, then, there’s your problem.

“It’s rare that printing nothing at all is the best default behavior.”

Aanand Prasad, Ben Firshman, Carl Tashian, and Eva Parish put together Command Line Interface Guidelines for people who write command-line tools.

I like that it harkens and links back to other writing, and is also pragmatic: shares good parameter-parsing libraries, commonly used options, and so on.

Here are some good principles that caught my attention:

Display output on success, but keep it brief. Traditionally, when nothing is wrong, UNIX commands display no output to the user. This makes sense when they’re being used in scripts, but can make commands appear to be hanging or broken when used by humans. For example, cp will not print anything, even if it takes a long time.

It’s rare that printing nothing at all is the best default behavior, but it’s usually best to err on the side of less.

By default, don’t output information that’s only understandable by the creators of the software. If a piece of output serves only to help you (the developer) understand what your software is doing, it almost certainly shouldn’t be displayed to normal users by default—only in verbose mode.

Catch errors and rewrite them for humans. If you’re expecting an error to happen, catch it and rewrite the error message to be useful. Think of it like a conversation, where the user has done something wrong and the program is guiding them in the right direction. Example: “Can’t write to file.txt. You might need to make it writable by running ‘chmod +w file.txt’.”

Signal-to-noise ratio is crucial. The more irrelevant output you produce, the longer it’s going to take the user to figure out what they did wrong. If your program produces multiple errors of the same type, consider grouping them under a single explanatory header instead of printing many similar-looking lines.

Consider where the user will look first. Put the most important information at the end of the output. The eye will be drawn to red text, so use it intentionally and sparingly.

Make it recoverable. If the program fails for some transient reason (e.g. the internet connection went down), you should be able to hit <up> and <enter> and it should pick up from where it left off.

There’s a lot more inside.

(The document is undated, but I believe the effort started in 2020. It seems to still be updated via GitHub, where you can also send in your suggestions.)

“Cryptic mode was born from a hard constraint.”

Software engineer Ajitem Sahasrabuddhe recently wrote a 6-post series called “Iron Core” about airline ticketing infrastructure. The entire series is probably too software engineer-y for us, but the third part has some interesting info about a particular 1960s user interface called “cryptic mode”:

Cryptic mode was born from a hard constraint: teletype terminals in the 1960s billed by the character transmitted. Every keystroke cost money. A command that took 50 characters instead of 10 cost five times as much. Commands were compressed to the absolute minimum.

The result is a domain-specific language whose syntax was shaped entirely by economics. AN for Availability Next. SS for Sell Segment. NM for Name. ER for End and Retrieve. No vowels wasted. No words spelled out.

Apparently the official name is “native mode,” but it gained its nickname because… well, see for yourself.

Asking the system for “Availability for Next flight” for February 8, from Nagpur to Delhi, is just 13 characters:

AN08FEBNAGDEL

And the system responds in an equally mysterious way:

** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000
1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0
2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0
3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0

With time these commands became wrapped inside more approachable interfaces and GUIs. But they exist under the hood and…

Many experienced travel agents still use it today alongside, and sometimes instead of, web-based agent interfaces such as Amadeus Selling Platform Connect. For a trained operator working a booking-heavy workflow, it is faster than the equivalent graphical interface for the same sequence of operations.

Except today, you get to choose. At the beginning, when “online” didn’t imply internet, and registration computers looked like this, you didn’t have a choice: this was the language you had to fluently write and read.

It makes Unix commands, also intentionally short/​cryptic, look like Microsoft Bob.

“It’s just a nice thing to have, you know.”

An 8-minute video by Bread on Penguins about some fun uses of terminal:

I am pretty sure this is nothing new for heavy command-line gurus (and heavy Raycast users, and so on), but I found it delightful to see someone so excited about creative uses of the terminal, and it made me realize how much time I do waste going through the browser, then Google Search, then scrolling. I am sure tightening some of these loops would feel great.

There is also something interesting in the argument about terminal being the ultimate “reading mode” of any website, chiefly because it cannot be anything else.

Mostly, this and Strudel before make me excited to see some new (to me) stuff happening with text-based user interfaces.

“You’d get knuckle pain if you typed too much.”

I’m slightly suspicious of this story (and the video inside) that Unix commands were made so short (cp instead of copy, mv instead of move, ls instead of list, and so on) because the console keyboard had really unpleasant keys.

I imagine it must be a confluence of many things, not just this one. Shorter means faster even with amazing keyboards. Shorter also means the commands travel quicker over the slow modems of the era. The downsides were limited: the early nerdy user base of Unix could handle the extra confusion.

On the other hand – no pun intended – I typed on the keyboard on the picture and I can confirm it is absolutely, positively atrocious, with the tallest keys you have possibly seen:

At any rate, it’s a good a reminder of the power of motor memory, and the difficulty of change management. Even the worst keyboards imaginable are so much better now, and the modems so much faster. And yet, the short and confusing commands remain to this day.