Unwritten Rules of Terminal Programs

I've spent countless hours in terminals, and something odd keeps striking me. Despite no central command telling developers how to build CLI tools, they all speak roughly the same language. q quits. Ctrl-C cancels. Colors disappear when you pipe output somewhere else.

This isn't accident. It's evolution.

The consistency comes from POSIX standards, old Unix conventions, and sheer momentum. Once enough tools agree on something, disagreement becomes a user experience problem. Below are the patterns I've noticed, the ones that make the command line feel intuitive even when you're using something completely new.

---

The Unwritten Rules

Color and Display Guidelines

Keybindings and Input Conventions

Rule 5: Vaguely Support Readline Keybindings

Users bring expectations from bash. These should mostly work:

• Ctrl-E jumps to the end of the line
• Ctrl-A jumps to the beginning
• Ctrl-W deletes the last word

Do you need full readline compatibility? Probably not. But users will try Ctrl-A in your tool expecting it to work. When it doesn't, they notice.

What's the "last word" anyway? For most programs it's space-delimited. Ctrl-W in bash delete everything back to the last space. That behavior comes from cooked mode in the OS terminal driver, so it's what users expect.

Rule 7: A Hyphen Means Stdin or Stdout

This one surprised me when I first noticed it. Many CLI tools accept a single hyphen as a special argument meaning "read from stdin" or "write to stdout."

Some examples: cat - reads from stdin tar cf - /path |-gzip > file.tar.gz streams archive to stdout diff file1 - compares file1 against stdin

It's a convention, not a requirement. But when you see it, you'll understand what the author meant.

Why Does This Matter?

Here's the thing. These patterns aren't rules someone wrote down and enforced. They're emergent. When enough tools do something one way, users learn that way. New tools inherit the same behavior because defying it creates friction.

I remember the first time I used a tool that didn't respond to q for quitting. It was some custom TUI for managing Docker containers. I hit q. Nothing. I hit Ctrl-C. Nothing. I had to kill it with Ctrl-Z and kill -9. It felt broken, even though it probably worked "correctly."

That's the point. In the terminal, convention IS correctness. If your tool fights user expectations, it's wrong, regardless of what your documentation says.

The CLI Guidelines project tries to formalize some of this. It's worth reading. But honestly, the fastest way to learn these conventions isn't reading at all. It's using the terminal daily. The patterns sink in through muscle memory.

A Pattern Worth Noticing

Next time you're exploring a new CLI tool, try this. Watch how it handles interrupts. Notice whether colorful output vanishes when you pipe it somewhere. Observe what happens when you press Ctrl-A in an input field.

You'll start seeing the patterns everywhere. Because they're not accidents. They're the accumulated decisions of decades, converging on a shared understanding of how terminals should work.

And that strangeness I mentioned at the start? The "strange harmony" of unrelated commands behaving consistently? It's not strange at all when you realize it comes from the same source as language itself. Convention. Repetition. Time.

Your tools are speaking the same dialect because we all learned it from each other.

You Might Also Like

• Why pipes sometimes get "stuck": buffering
• SSH and SCP: The Two Tools Every Developer Should Actually Understand
• High-Throughput Linux I/O in Rust: io_uring, Tokio & Zero-Copy Networking
• Building High-Throughput Microservices with Rust and Axum: Complete Production Guide

Test Your Knowledge