The Art of Unix Programming (TAoUP), by Eric S. Raymond, is not a tutorial or how-to book. Instead, it is a book about the history and philosophy of Unix. But no other book has had a greater influence on my approach to Linux/macOS, or my everyday use of it. Here are just a few of the things it has taught me.
6
Unix Is (Even) Older Than You Think
You don’t need to know the full history of Unix to use it—or Linux, or macOS—today. But knowing a bit about how Unix originated cannot hurt. Understanding the context of the OS helps you understand the screen you’re looking at, and history can answer many of your initial questions, like “Why are command names so short?”
The second chapter—“History: A Tale of Two Cultures”—explains how Unix began in 1969, on teletype machines that looked like glorified typewriters. It’s amazing to think that these machines still have something in common with many of the servers that power our lives online.
Nowadays, it’s fine to think of Linux as a Unix clone, which it essentially is. But that history is far longer and richer than it may seem, and I take pride in using a system with fifty-year-old roots, even in the face of every technological advance since then.
5
Open Source Would Be Nothing Without Linux
TAoUP goes on to cover the birth of Linux and how Linus Torvald’s approach was a compromise between proprietary, locked-down systems and the ideological freedom that the burgeoning open-source movement lived by.
The open-source movement is so vital to Linux’s story, that it’s easy to consider them one and the same. But it’s fascinating to find out more about the history of open-source and how it compares with the proprietary approach or the GNU alternative (“free software”).
As far back as the 1950s, engineers were sharing source code, reading it, and modifying it. But it was only in the 1990s, when Linux arrived on the scene, that open-source software started to be widely used. This coincided with wider availability of the internet, a distribution mechanism that enabled open-source development to really take off.
Related
4
Linux Embraces Simplicity (Honest!)
Although it may seem complicated at first, Linux is built on simple fundamental principles. If there is one lesson the book teaches more than any other, it’s this. The whole design section (chapters 4–13) explains why the basic Unix ethos is so beneficial.
Raymond explores this concept by breaking it down into a set of “rules” that the “elders” of Unix (people like Rob Pike and Ken Thompson) had previously stated less formally. These 17 rules include:
- Modularity
- Composition
- Simplicity
- Transparency
- Silence
The rules essentially boil down to a familiar principle: KISS (Keep it simple, stupid!) By encouraging small programs, that perform basic, concrete tasks and communicate using a simple text protocol, the Unix philosophy results in reusable, reliable tools.
Related
People in the ’80s Thought Unix Would Take Over. Here’s Why They Were Right
The legacy of Unix lives on. Big hair, not so much.
3
Precise, Modular Programs Make Everything Tick
The first of Raymond’s rules is “Modularity,” which is described as, “Write simple parts connected by clean interfaces.” Like many of the other rules, the focus here is on controlling complexity. Many problems with computer use arise from complex systems that are difficult to understand. By championing simplicity, this rule aims to reduce failures and improve overall understanding.
When you first encounter Linux tools like ls or grep, it can be difficult to consider them as full-blown programs in their own right. They do far less than your web browser or your word processor, so they can seem trivial or unimportant. But that overlooks the inherent power of modularity: combining small programs to achieve more than the sum of their parts.
One of the most practical examples of the power of modularity is the pipe:
ls | grep "foo"
Here’s an example of a very common pattern that I find myself reaching for, time and time again:
du -sk * | sort -rn | head
This pipeline runs three programs: du to report the total size of matching files/directories, sort to order them numerically, and head to return the first ten results. The result is a small set of directories that take up the most space on the disk, which I can then follow up on to clean up.
Without pipes, the alternative would be a single program called something like “get-biggest-ten-folders.” Such a program may even be more convenient, but it’s far more restricted than the general tools available here. You would need a huge number of awkwardly named programs to get by without pipes, and their complexity would no doubt be horrible to work with.
2
Text Underpins Everything
Chapter 5 of the book is all about textuality, both in terms of file formats and the way that Unix programs communicate. This was one of the things that struck me most about Unix, especially when it comes to configuration. Coming from Windows, I was used to the registry, that infamous, opaque, monolithic database that houses program settings.
Linux tools, in contrast, tend to have text-based config files, dotted all over your filesystem (in standard places, if you so choose). You can edit these files with a standard text editor, and query them with commonly available command-line tools. This means there’s no requirement for custom GUI tools to change settings, although these can still be built on top of the traditional text file format.
This philosophy extends to how programs communicate too. When you use a pipeline, you’re passing text from one program to another. At any point, you can interrupt the pipeline to debug it. Take this pipeline as an example:
ls | grep "txt"
By inserting the tee command, you can capture the output at a specific point and save it to a file for debugging:
ls | tee debug-ls-output.txt | grep "txt"
This ties into Raymond’s Rule of Transparency:
“Design for visibility to make inspection and debugging easier”
Using text as a communication and data format means that programs operate in the open, with fewer hidden parts. This makes it easier to fix programs, learn from them, and use them.
1
Linux Is Stubbornly Traditional, for Good and Bad
Linux—and, more so, Unix—is often looked down upon as “old-school”, a system beloved by “grey-beards” and zealots. While there may be an element of truth to that, it overlooks the fact that mature, evolved technologies aren’t necessarily bad.
In chapter 14, Raymond discusses the use of C, which has been instrumental in Linux’s development. Although the situation is evolving, many of the standard command-line tools are still written in C today. The book notes how C has proliferated, in part, because of the excellent tooling support that has survived the passing of time.
Raymond is not an absolutist; he explains how Python, a relatively modern language, is a superior choice for new projects. But he also explores the benefits and drawbacks of shell programming and argues that object-oriented programming is not perfect. Like much of the book, this section argues against one-size-fits-all solutions and emphasizes how context is always important.
The Art of UNIX Programming
$35 $55 Save
$20
This book explores the origin and philosophy behind UNIX, as well as how it evolved over the decades into modern operating systems.
The Art of Unix Programming is available online for free and as a hard copy. I’m a big fan of both because the former is great for reference, but the book is such a good read that it’s nice to sit back and explore cover-to-cover.
