What do you think?
Rate this book
The Art of UNIX Programming
The Art of UNIX Programming poses the belief that understanding the unwritten UNIX engineering tradition and mastering its design patterns will help programmers of all stripes to become better programmers. This book attempts to capture the engineering wisdom and design philosophy of the UNIX, Linux, and Open Source software development community as it has evolved over the past three decades, and as it is applied today by the most experienced programmers. Eric Raymond offers the next generation of "hackers" the unique opportunity to learn the connection between UNIX philosophy and practice through careful case studies of the very best UNIX/Linux programs.
560 pages, Paperback
First published January 1, 2003
162 people are currently reading
2657 people want to read
About the author
Eric S. Raymond
23 books143 followersEric S. Raymond is an observer-participant anthropologist in the Internet hacker culture. His research has helped explain the decentralized open-source model of software development that has proven so effective in the evolution of the Internet. Mr. Raymond is also a science fiction fan, a musician, an activist for the First and Second Amendments, and a martial artist with a Black Belt in Tae Kwon Do.
--from the author's website
--from the author's website
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 62 reviews
January 14, 2010
This book is about programming. Still, there is almost not a single snippet of code in this 500 page book. Instead it focuses on the philosophy that has developed within the UNIX community over the years. There is a lot of knowledge to be found here, even if you don't develop for, or even like UNIX systems. It has got comments from early UNIX hackers, even some of the original creators, which enrich the text and gives a broader perspective on things in some cases.
The fact that many sections includes historical perspective alone makes this an interesting read. This field is very young after all, and makes you think of how far (or not) we've come since the 70's. It also contrasts UNIX to other operating systems, and the way programs are built on these, since a huge point is that the environment you work in greatly influences how you think of things. For instance, UNIX programs tend to be small, specialized and made to work collaboratively, while Windows programs tend to grow quite big, have many features and do everything by itself.
The comments and evaluation, in respect of the UNIX philosophy, of wide ranging things, such as IPC, configuration and domain specific languages are very interesting. But if you're not an Emacs user (like me), prepare yourself to hear a lot of evangelism.
The fact that many sections includes historical perspective alone makes this an interesting read. This field is very young after all, and makes you think of how far (or not) we've come since the 70's. It also contrasts UNIX to other operating systems, and the way programs are built on these, since a huge point is that the environment you work in greatly influences how you think of things. For instance, UNIX programs tend to be small, specialized and made to work collaboratively, while Windows programs tend to grow quite big, have many features and do everything by itself.
The comments and evaluation, in respect of the UNIX philosophy, of wide ranging things, such as IPC, configuration and domain specific languages are very interesting. But if you're not an Emacs user (like me), prepare yourself to hear a lot of evangelism.
Read
November 23, 2019I wanted to love this book, but INSTEAD I just sort of liked it. The book definitely was not a bad read, but it did not fit my needs.
Want to read
April 18, 2010Available at http://catb.org/~esr/writings/taoup/h...
November 26, 2021
WIP, will review later
August 15, 2022
Ce livre est l’un des livres mythiques sur UNIX et le mouvement open source écrit par un de ses plus fervents défenseurs Eric S. Raymond. Dans le titre du livre figure le mot art et c’est bien sous cet angle ou plutôt sous celui de la philosophie que Raymond articule son ouvrage. Il propose de tirer la quintessence de ce qui a fait le succès d’UNIX, et de ses successeurs comme Linux, pour en extraire des règles, des principes et des bonnes pratiques qui seraient généralisables. Certains sont désormais très connus comme “Premature optimization is the root of all evil” ou le principe KISS certains le sont un peu moins comme les principes de compacité et d’orthogonalité. Pour les illustrer, il s’appuie sur les implémentions d’UNIX et sur celles d’autres outils open source.
Pour les amateurs – comme moi –, la partie historique est un régal, on apprend plein de choses, les cas d’études sont moins intéressants principalement parce qu’ils ont beaucoup et mal vieilli. Le reproche que l’on pourrait adresser à ce livre et à son auteur, est d’être partisan, mais c’est aussi ce qui en fait le sel. Forcément, Microsoft – le camp d’en face – en prend pour son grade dès que l’occasion se présente.
Et il ne se gène pas non plus pour égratigner le gourou du free software Richard M. Stallman avec lequel il ne partage pas la même vision.
Il reste de cette lecture un bon moment au cours duquel j’ai complété mes connaissances sur l’histoire de l’informatique et sur des principes qui restent pour la plupart, et malgré les années, toujours pertinents. En bonus, une tonne de citations qui sont de petits bijoux comme celle-ci.
Également publié sur mon blog.
Pour les amateurs – comme moi –, la partie historique est un régal, on apprend plein de choses, les cas d’études sont moins intéressants principalement parce qu’ils ont beaucoup et mal vieilli. Le reproche que l’on pourrait adresser à ce livre et à son auteur, est d’être partisan, mais c’est aussi ce qui en fait le sel. Forcément, Microsoft – le camp d’en face – en prend pour son grade dès que l’occasion se présente.
In 1981, Microsoft made its historic deal with IBM over the new IBM PC. Bill Gates bought QDOS (Quick and Dirty Operating System), a clone of CP/M that its programmer Tim Paterson had thrown together in six weeks, from Paterson’s employer Seattle Computer Products. Gates, concealing the IBM deal from Paterson and SCP, bought the rights for $50,000. He then talked IBM into allowing Microsoft to market MS-DOS separately from the PC hardware. Over the next decade, leveraging code he didn’t write made Bill Gates a multibillionaire, and business tactics even sharper than the original deal gained Microsoft a monopoly lock on desktop computing.
Et il ne se gène pas non plus pour égratigner le gourou du free software Richard M. Stallman avec lequel il ne partage pas la même vision.
Il reste de cette lecture un bon moment au cours duquel j’ai complété mes connaissances sur l’histoire de l’informatique et sur des principes qui restent pour la plupart, et malgré les années, toujours pertinents. En bonus, une tonne de citations qui sont de petits bijoux comme celle-ci.
Beauty is the ultimate defense against complexity.
Également publié sur mon blog.
July 14, 2010
Victory!!! I have finally completed this book. The book weighs in at just under 500 pages, but it reads much longer than that (at least for me) I don't want to imply that that is negative though, the book is wonderful, and is an absolute must read for any software developer. It just took me 3 months to read, which is significantly longer than I would have thought, or originally wanted.
This book does a very good job of explaining the culture and history of unix, but all of those cultural and historical lessons are written in the context of how they drove or were the result of technical decisions.
Chapter 1 lays out 13 rules of the Unix philosophy, and constantly comes back to them when discussing the design of a particular unix program. If the program breaks one of the rules, Raymond points it out, explaining why it was a poor decision to do so.
The 13 rules themselves would be worth the price of admission. If you can only read one chapter, make it chapter 1.
This book does a very good job of explaining the culture and history of unix, but all of those cultural and historical lessons are written in the context of how they drove or were the result of technical decisions.
Chapter 1 lays out 13 rules of the Unix philosophy, and constantly comes back to them when discussing the design of a particular unix program. If the program breaks one of the rules, Raymond points it out, explaining why it was a poor decision to do so.
The 13 rules themselves would be worth the price of admission. If you can only read one chapter, make it chapter 1.
Read
June 19, 2014Good book. There were a lot of things in here that I've felt for a long time but was not sure how to explain. For example, the discussion of why config files should be human readable made me realize why I was so opposed to an advisor's suggestion that our config file be a giant ugly s-expression on a project I did last year; it also made me realize why I felt that the backend for that project should use sockets to communicate with the GUI (because it encourages modularity, keeps GUI code out of real program logic, allows new interfaces to be easily added, allows GUI to run on a separate machine than the back end; we'd only though of the last). Not all was justification though; I also learned lessons about good ways to format and output errors and how much our testing process sucked.
February 7, 2015
The history section alone is worth it. Nathan Marz's mantra of "first make it possible, then make it beautiful, then make it fast" clearly were taken from this philosophy. A nearly identical mantra is stated in the first pages of this book.
History is doomed to repeat itself.
I first read the chapter on Textuality, and have since gone back and started from the beginning. So far this book is excellent.
History is doomed to repeat itself.
I first read the chapter on Textuality, and have since gone back and started from the beginning. So far this book is excellent.
June 30, 2016
This book is more about the learnings/lessons from Unix world. Mostly historical descriptions and why certain choices were made by Unix and how they were revolutionary as compared to other operating systems. Lots of practice case studies are included wherein how and why certain choices were made by certain popular programs were made.
A very quick read for me - more of like a refresher -as I was already well versed with the historical developments.
A very quick read for me - more of like a refresher -as I was already well versed with the historical developments.
August 6, 2008
Curiously Raymond managed not to read Gancarz's classic The Unix Philiosophy while writing this. It doesnt cover quite the same ground, and is much less concise. Its bigger on scripting languages and other more recent developments.
August 23, 2009
An extended argument for the genius of UNIX.
February 22, 2025
After 180 pages or so, I mostly skimmed this book.
There are a lot of problems here that I will try putting into words. From the very start, the reading experience is very jarring. Now, I have a lot of software engineering experience, and I believe it is not down to the technical complexity. I found that the writing style of the book contributes to this feeling. Some of the sentences are so long that, by the time you reach the 3rd line in the sentence, you are already lost. I found myself reading these kind of sentences 3-4 times just to make sense of them. Considering, it is not a textbook, I don't understand the need for that. The vocabulary adds to the feeling, words like surcease make rather unwelcome unappearance.
However, I feel the major cause is the organization. The book presents a lot of case studies for each of the Unix principles it presents. So in a chapter, you might come across 5-10 shorts studies (spanning 1-2 pages, sometimes shorter). And therein lies the problem. Jumping across so many different types of concepts which can't go into required detail would always be jarring. Perhaps, it would have been better to present an example of a study end to end like fetchmail, and then discuss all the unix principles it embodies. It would have certainly made for a more compelling study, atleast for me. It would have led to continuity of the topic.
Another problem with the book would always be that it is quite old, and some obscure technologies like CORBA, XML-RPC are legacy or mostly irrelevant.
I find it hard to understand what kind of audience this book caters to. To Unix fanboys maybe? In terms of good programming practices, there are focused, well-written books, same goes for system design. Is it a book or is it more of a dissertation on the Unix principles and how they have been applied successfully?
As someone else mentioned in the reviews, reading the chapter 1 might be enough, which is quite good. I feel rather generous giving 2 stars here, on the basis of how it stands together as a book.
There are a lot of problems here that I will try putting into words. From the very start, the reading experience is very jarring. Now, I have a lot of software engineering experience, and I believe it is not down to the technical complexity. I found that the writing style of the book contributes to this feeling. Some of the sentences are so long that, by the time you reach the 3rd line in the sentence, you are already lost. I found myself reading these kind of sentences 3-4 times just to make sense of them. Considering, it is not a textbook, I don't understand the need for that. The vocabulary adds to the feeling, words like surcease make rather unwelcome unappearance.
However, I feel the major cause is the organization. The book presents a lot of case studies for each of the Unix principles it presents. So in a chapter, you might come across 5-10 shorts studies (spanning 1-2 pages, sometimes shorter). And therein lies the problem. Jumping across so many different types of concepts which can't go into required detail would always be jarring. Perhaps, it would have been better to present an example of a study end to end like fetchmail, and then discuss all the unix principles it embodies. It would have certainly made for a more compelling study, atleast for me. It would have led to continuity of the topic.
Another problem with the book would always be that it is quite old, and some obscure technologies like CORBA, XML-RPC are legacy or mostly irrelevant.
I find it hard to understand what kind of audience this book caters to. To Unix fanboys maybe? In terms of good programming practices, there are focused, well-written books, same goes for system design. Is it a book or is it more of a dissertation on the Unix principles and how they have been applied successfully?
As someone else mentioned in the reviews, reading the chapter 1 might be enough, which is quite good. I feel rather generous giving 2 stars here, on the basis of how it stands together as a book.
September 26, 2019
The book includes an overview of core Unix principles and philosophies, such as:
Rule of modularity - write simple parts connected by clean interfaces
Rule of clarity - clarity is better than cleverness
Rule of composition - design programs to be connected with other programs
Rule of separation - separate policy from mechanism; separate interfaces from engines
Rule of simplicity - design for simplicity; add complexity only where you must
Rule of parsimony - write a big program only when it is clear by demonstration that nothing else will do
Rule of transparency -design for visibility to make an inspection and debugging easier
Rule of robustness - robustness is the child of transparency and simplicity
Rule of representation -fold knowledge into data, so program logic can be stupid and robust
Rule of least surprise - in interface design, always do the least surprising thing
Rule of silence - when a program has nothing surprising to say, it should say nothing.
Rule of repair -repair what you can—but when you must fail, fail noisily and as soon as possible
Rule of economy - programmer time is expensive; conserve it in preference to machine time
Rule of generation - avoid hand- hacking; write programs to write programs when you can
Rule of optimization - prototype before polishing. Get it working before you optimize it.
Rule of diversity - distrust all claims for “one true way"
Rule of extensibility - design for the future, because it will be here sooner than you think
With which I completely agree. Other than that book consist of a lot of history and case studies of tools, which are nowadays mostly obsolete.
Rule of modularity - write simple parts connected by clean interfaces
Rule of clarity - clarity is better than cleverness
Rule of composition - design programs to be connected with other programs
Rule of separation - separate policy from mechanism; separate interfaces from engines
Rule of simplicity - design for simplicity; add complexity only where you must
Rule of parsimony - write a big program only when it is clear by demonstration that nothing else will do
Rule of transparency -design for visibility to make an inspection and debugging easier
Rule of robustness - robustness is the child of transparency and simplicity
Rule of representation -fold knowledge into data, so program logic can be stupid and robust
Rule of least surprise - in interface design, always do the least surprising thing
Rule of silence - when a program has nothing surprising to say, it should say nothing.
Rule of repair -repair what you can—but when you must fail, fail noisily and as soon as possible
Rule of economy - programmer time is expensive; conserve it in preference to machine time
Rule of generation - avoid hand- hacking; write programs to write programs when you can
Rule of optimization - prototype before polishing. Get it working before you optimize it.
Rule of diversity - distrust all claims for “one true way"
Rule of extensibility - design for the future, because it will be here sooner than you think
With which I completely agree. Other than that book consist of a lot of history and case studies of tools, which are nowadays mostly obsolete.
July 29, 2021
This book is a CS classic.
Now, as more than a billion computers (ie /servers/smartphones/notebooks) run a Linux operating system, software running Unix derivates is ubiquitous. That was not the case when this classic book was written in 2003.
The original creators of the Unix operating system reflect on the design decisions they made in the 1970s, 80s and 90s as well as the underlying philosophy that guides the suite of software tools running on Unix (now eclipsed by Linux). These deliberate, as well as evolved design choices are the the reason that made this suite of software tools so great that this software later conquered the server and smartphone market.
Half of the pages and software mentioned in this book is now obsolete, as twenty years have passed since the publication. But the remaining content contains distilled wisdom from 30 years of development.
Now, as more than a billion computers (ie /servers/smartphones/notebooks) run a Linux operating system, software running Unix derivates is ubiquitous. That was not the case when this classic book was written in 2003.
The original creators of the Unix operating system reflect on the design decisions they made in the 1970s, 80s and 90s as well as the underlying philosophy that guides the suite of software tools running on Unix (now eclipsed by Linux). These deliberate, as well as evolved design choices are the the reason that made this suite of software tools so great that this software later conquered the server and smartphone market.
Half of the pages and software mentioned in this book is now obsolete, as twenty years have passed since the publication. But the remaining content contains distilled wisdom from 30 years of development.
April 5, 2018
An excellent book, although I think the title is badly chosen because it's a bit of a misnomer and could put people off: the title implied to me that it would be about how to code for UNIX, what it *actually* is is the philosophies and design decisions that have influenced UNIX and why they were made. I think you could read this book without being a programmer and still get something out of it, however I also think that some familiarity of common UNIX tools would help as a number of them are used as case studies. Being written in 2003 it is a little dated but the vast majority of the advice in it stands up and of course the history it covers hasn't changed.
July 7, 2022
It's weird reading these kinds of books. It's like reading stories from a religious text. Using situations which are either timeless or outdated they describe how one might come to a fine course of action. It's not telling me how UNIX is today, but it tells me of the foundation that later decisions were built on.
I'm overall glad I read it. It gave me a history lesson and many different things to think about (and suggested readings).
I guess I don't find too much of this practical advice purely because it echoes through comments on reddit/hacker new/lobsters. I've already heard of the core concepts and approaches before.
I'm overall glad I read it. It gave me a history lesson and many different things to think about (and suggested readings).
I guess I don't find too much of this practical advice purely because it echoes through comments on reddit/hacker new/lobsters. I've already heard of the core concepts and approaches before.
January 2, 2019
Great book albeit quite biased against Microsoft and looks down on all other software/OSes. The last chapter offers some critical reflection on this pride.
I really enjoyed the software-related discussions on design and implementation methodologies. The talk of transparency and discoverability being critical to ease of software maturity and usage.
The book's age however shows in the dead links and outdated sections (e.g. on JavaScript, web browsers etc.).
Great read though and full of wisdom.
I really enjoyed the software-related discussions on design and implementation methodologies. The talk of transparency and discoverability being critical to ease of software maturity and usage.
The book's age however shows in the dead links and outdated sections (e.g. on JavaScript, web browsers etc.).
Great read though and full of wisdom.
December 24, 2019
While dated (published in 2003), this book covers a large amount of relevant history that help explain *why* Unix is the way it is.
I lived through about half the history that was covered and experienced about a decade and a half. Despite being a professional programmer for twenty years, I felt like I learned a lot from this book.
While I have heard most of the Unix programming maxims before, this book really filled in the history and reasoning behind the sayings. I think this would be a valuable read for developers who aren’t well versed in Unix history.
I lived through about half the history that was covered and experienced about a decade and a half. Despite being a professional programmer for twenty years, I felt like I learned a lot from this book.
While I have heard most of the Unix programming maxims before, this book really filled in the history and reasoning behind the sayings. I think this would be a valuable read for developers who aren’t well versed in Unix history.
February 10, 2020
There are lots of wisdom in the book, The information in the book is relevant today. The discussions about tools, such as sed, cat, awk are interesting since he says they have survived the trial of time, 17 years later and still in use. Vi and Emacs are two editors that survived the trial aswell.
In the end, the aspect of developing tools for non-developers is still a struggle today. For example, Jenkins is a high performance and the GUI leaves lots of things to wish for. Not that it was an example of the book, but still it proves his point.
In the end, the aspect of developing tools for non-developers is still a struggle today. For example, Jenkins is a high performance and the GUI leaves lots of things to wish for. Not that it was an example of the book, but still it proves his point.
December 6, 2021
It's a dense book with a brief tour trough the pre historical unix and many aspects regarding the good practices involved in developing software the unix way. I'm sure I didn't absorbed everything that was shown, but I'm sure I got really good insights that would help me to become a better developer. I'll have to read it again somehow in the future, and certainly I'll be able to take more from it.
June 4, 2018
Wonderful book in my opinion. It really tells you why Unix (and Linux) are the way they are and the efforts that made it become what it is. To me, Linux is a great humanity achievement.
This book is technical without being technical, it really is about philosophy and principles rather than algorithms, syntax or other programming techniques. Could be seen as an encyclopedia.
This book is technical without being technical, it really is about philosophy and principles rather than algorithms, syntax or other programming techniques. Could be seen as an encyclopedia.
September 26, 2017
Enjoyable insight into some history of the UNIX world.
May 8, 2020
Even though it's dated and ESR isn't very popular these days, the book is really good. Explains a lot of concepts that many of us intuitively understand but have difficulty arguing for.
September 24, 2021
Pleasure to read
June 11, 2022
Amazing book. Here are the whys and hows. I don't know of any other book like this.
May 31, 2023
The best programming book I have ever read. Eric Raymond does a fantastic job of distilling the timeless wisdom of the UNIX philosophy.
March 4, 2024
Enjoyable and very useful. At the very least skim this for an understanding of how unix works. Had this as night time reading
June 17, 2025
Felt like reading a hacker's manifesto while standing in /bin. Changed how I design programs, permanently
June 20, 2020
Not exactly what I thought I was getting into, with much more discussion of the culture and history of UNIX than I expected, but nonetheless a pleasant read.
October 13, 2022
I expected this to be far more technical than it is. The book is worth reading for its description of UNIX history and culture and some basic design principles. Many portions, however, are very opinionated, yet offer only sparse insight. Where it's not historic, the text is very dated by now (as one can expect considering its origins in the late 90s to early 00s). Even in 2003 many of the projects selected as case studies were just irrelevant.
Fortunately, back then Eric S. Raymond hadn't yet shown to be a person as insufferable as he ist today. There are well-formatted PDFs available legally for free. I'd suggest to look at one of those, rather than support the author financially in any way (rest assured, he doesn't need your money).
Fortunately, back then Eric S. Raymond hadn't yet shown to be a person as insufferable as he ist today. There are well-formatted PDFs available legally for free. I'd suggest to look at one of those, rather than support the author financially in any way (rest assured, he doesn't need your money).
Displaying 1 - 30 of 62 reviews