Unix Philosophy: A Quick Look at the Ideas that Made Unix

Early on, developers working on Unix created a set of ideals that acted as a roadmap for the programs that they wrote. They didn't always follow these ideals, but they set the tone for the Unix project. To this day, the Unix Philosophy impacts many projects.

The Tenets of the Unix Philosophy

Unix Philosophy was first put into writing by Doug McIlroy in the 1978 Bell System Technical Journal.

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringent columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Later in 1994, McIlroy summarized these tenets in Peter H. Salus' A Quarter-Century of Unix.

• Write programs that do one thing and do it well.
• Write programs to work together.
• Write programs to handle text streams, because that is a universal interface.

There are several other versions of the Unix Philosophy, written by the founding fathers of Unix. Some are shorter and some are longer than the two versions listed above. For the purposes of this article, we will only be looking at the work of McIlroy.

Keep in mind that these ideas are not meant to be strictly followed. In his article Why the Unix Philosophy Matters, Markus Schnalke stated, "It is not a limited set of fixed rules, but a loose set of guidelines...to achieve good quality and high gain for the effort spent".

Keeping Programs Simple

We've all seen it: a program starts out with a simple premise in mind. Over time, the developer (or developers) keeps adding more and more features until the original purpose of the program is obscured. 

This inevitable feature creep brings us to Zawinski's Law of Software Envelopment, which states "every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." 

WordPress is a good example of Zawinski’s Law—though originally created to be a blogging application, it has become much more over time. Now, with the right plugins, it can be used for anything "from a discussion board engine to an e-commerce solution".

This is exactly what the Unix Philosophy is designed to avoid. The Unix tools are typically designed to do one thing, and do it well. `ls` is intended to list all the file in the current directory. `wc` counts the "number of newlines, words, and bytes" in a file. `grep` searches a text file for a string, and then prints out all the lines that contain that string. These are all small and simple applications that only have one job. This simplicity also makes it easier for a single person to understand the inner workings of a program. 

Design Programs to Work Together

Because Unix tools are designed to do one job, it's easy to take a series of Unix tools and string them together to perform a task. This can be accomplished using pipes, which were advocated by Doug McIlroy.

For example, if you wanted to search a text file with a customer list for every person with the first name Gary, you would combine `cat` and `grep`. It would look something like this: `cat customer_list.txt | grep Gary`.

Before you rush to award a “Useless Use Of Cat” here, keep in mind that we’re specifically discussing the Unix Philosophy. Yes, you can accomplish the same result in a single command with “grep Gary customer_list.txt” but the goal is not forcing grep to do every conceivable thing no matter what, it’s to showcase the ability to pipe the output of one command to the input of another.

Use Text as an Output

Plain text is a universal format that is extremely portable and easy to use. According to Eric S. Raymond's The Art of Unix Programming, "Text streams are a valuable universal format because they're easy for human beings to read, write, and edit without specialized tools. These formats are (or can be designed to be) transparent."

This tenet reminds the programmer to not add extra complexity to the output and possibly make it hard for other programs to use. It must be portable and usable by any other application. It can be easily edited by the user without needing special programs or tools.

Almost all proprietary software fails this tenet. Most of them tie up their output in file types that can only be understood by them, which becomes even more problematic when that software is no longer available. For a contrasting example, most FOSS software automatically disables colorized text when writing to a pipe—because it knows that the extra ASCII is likely to confuse other applications needlessly.

Test Early, Test Often

Being able to test a piece of software early allows the programmer to make sure that it works from the word go. Otherwise, there is a good chance that it will fail due to being based on a flawed foundation.

Testing early also helps the programmer to determine whether his idea will work or not. It uncovers any problems both with the original idea and in the implementation. If there are any issues, the programmer will be able to adjust the design before too much time has been wasted heading the wrong direction.

A great example of this idea can be found in the early days of Unix. Unix was originally created to help the patent department at Bell Labs write up their patent applications. At night, the development team would work on Unix and add new features. The next day, the patent department field tested the system.

Final Thoughts

Regardless of which version of the Unix Philosophy you follow, the end goal is to combat software complexity and promote portability. These ideas were created by people who had a lot of programming experience and spent time thinking about the best methods of creating clean and simple tools. 

For example, Ken Thompson, Dennis Ritchie, and their associates had spent the years between Multics and Unix discussing and thinking about what an operating system should look like. Arguably, the time that they spent thinking and discussing prevented headaches later on and helped deliver a simple, reliable system.