The Art of UNIX Programming

Eric S. Raymond

Unix ranks among the great engineering accomplishments of the last half of the twentieth century, and its heir--Linux--seems already imposing and still on its way to achieving its full potential. Eric S. Raymond argues in The Art of UNIX Programming that the excellence of Unix derives as much from the fact that it was (and continues to be) a community effort as from the fact that a lot of smart people have worked to design and build it. Raymond, best known as the author of the open-source manifesto The Cathedral and the Bazaar, says in his preface that this is a "why-to" book, rather than a "how-to" book. It aims to show new Unix programmers why they should work under the old "hacker ethic"--embracing the principles of good software design for its own sake and of code-sharing.

That said, a great deal of valuable practical information appears in this book. Very little of it is in the form of code; most of the practical material takes the form of case studies and discussions of aspects of Unix, all aimed at determining why particular design characteristics are good. In many cases, the people who did the work in the first place make guest appearances and explain their thinking--an invaluable resource. This book is for the deep-thinking software developer in Unix (and perhaps Linux in particular). It shows how to fit into the long and noble tradition, and how to make the software work right. --David Wall

Topics covered: Why Unix (the term being defined to include Linux) is the way it is, and the people who made it that way. Commentary from Ken Thompson, Steve Johnson, Brian Kernighan, and David Korn enables readers to understand the thought processes of the creators of Unix.

1 Programming?
I don't understand how people can publish books like this . . . "The Art of UNIX Porgamming" does not have a single line of code in it! All it contains is a bunch of opinions from a guy who thinks he is a UNIX programming wizard, but whose total contribution to programming is the single program "fetchmail". His biases show clearly as he actually lists "elsip" as a programming language! While LISP is indeed a very powerful programming language, elisp is nothing more than a way of customising the EMCAS text editor! Many of his other statments border on the ridiculous, such as his notion of object oreinted programming languages as a "failed expermient". Ever heard of C++ or Java? You can hardly get a job nowadays without knowing both, and they are both OO languages!

If you want a *real* programming book, try Stephens' "Advanced Programming in the UNIX Environment" which actually has code in it and shows you how to use it under UNIX. Stephens' book actually show you *how* to program in UNIX as opposed as to just talking about it.

This book is available online so peruse it at ESR's webiste instead of buying this overpriced, worthless piece of verbiage.

2 Indispensable
I've been using, administering, and teaching UNIX since 1991 without the benefit of any formal instruction. That means I rely on books. I just got a desk copy of The Art of UNIX Programming and found it to be one of the very best UNIX books I've ever seen. Although it's not a text I'll strongly recommend it to students in all of my classes.

ESR's writing style is excellent. The information density is very high but the book is an easy and engaging read, in fact the first time through it was hard to put down. The inclusion of historical anecdotes, caustic comments, and even koans keep it lively. Technically it's rather high level with very little fine detail. For details consult UNIX for the Impatient.

The book is as much about using UNIX as it is about programming with UNIX. I suppose these points of view are inseparable, after all why bother to use UNIX if you don't want to tell your computer what to do? The point is this book is useful to non programmers and occasional programmers. ESR fills far more space discussing things like file formats, XML, shells, editors, and documentation than he does explaining C. Understanding how these pieces work and fit together is essential to using UNIX productively.

This is not a high school history book edited to be free of all content which might possibly offend someone. If you're a Windows partisan you'll have to get past more than a few uncomplimentary references. Even if you disagree, you can take the knocks as enlightening you on the considerable philosophical differences between UNIX and Windows. ESR also doesn't hesitate to point out areas of difficulty within UNIX, now I understand exactly why I have problems with vi and sendmail.cf.

This book is old school, but then so is UNIX itself. This book will help you understand the history of what went right, what went wrong, and why; and that will help you make better use of UNIX today and tomorrow.

3 A great book about Unix
I read the book first in its HTML form, from Raymond's site, and I felt need to buy the real book.
Its format is very appropriate and shows the best we have in Unix.
Even though I have a degree in chemical engineering, I found it to be a valuable resource for my own projects for open source development.

4 Good sound advice
I purchased this book as soon as it was avalible is September 2003. Mr. Raymond gives good sound advice that this Computer Science student has taken to heart is his studies. The advice is so simple, obvious, and logical that you will find yourself wondering why you didn't think of these things in the first place.

Along with good advice this book also gives an insightful history of UN*X and some suggestions as why it is not "King" of the desktop today, as it should be.

Further into the book there numerious examples of good programming practices; featuring programs that follow the traditional UN*X philosophy of coding. This book also explains the many pitfalls that seem so prevenent programming practices. I say this as an experenced computer user not as programmer. With these observations I hope to become a quality UN*X programmer.

It has been noted in an other review that Mr. Raymond is big into the Linux community. Yes this is true. He is one of Linus Torvalds's right hand men and spokesmen. Mr. Raymond, to his credit, touches very little on the subject of Linux of his known dis-liking of M$ in this book.

This book will forever be in my library of programming books. You will never catch my copy of this book here on Amazon as a used book. (Unless of course I am starving to death or I am already dead and my family is selling off my stuff.) I would like to thank Mr. Raymond for sharing his many years of UN*X expertise. (I would actually like to meet him some day.)

5 an interesting and often annoying read...
I suppose any book containing so many interesting quotes from so many UNIX luminaries cannot be overlooked. (I wonder if any of them would have co-authored this) It also happens to contain a great many topics that are well-worth writing about; My only wish is that someone less in awe with the contents of his own field of vision, and with greater depth and objectivity (not to mention humility) had the opportunity to write this book.

Quality of discussion is varied as expected; Raymond is not quite the UNIX expert he thinks he is. In places, Raymond's tone encourages one to throw the book at the nearest wall and go out just to get some fresh air; He is condescending, hectoring, lecturing, and sometimes just misleading. Alas, I will still recommend it as worth reading (check your local library) with a nice grain of salt; just enough friction for thought is provided in this edition.

6 Has he ever used unix?
This book isn't about unix programming, its about the authors idea of linux programming. I will teach you bad habits and how to make non-portable linuxware. Do the unix world a favor, and skip this one.

7 Finally, an excellent book for programmer
I was able to spend a couple of months finishing this book. As soon as I finished the first chapter, I know the book would be an excellent one, and it does not disappoint me from the beginning to the end.

I have been using Unix (and its variants) for a decade amd have quite some knowledge about "how-to", but probably like most other Unix programmers, have never systematically thought about the underlying "why". This book is going to tell you both in details.

The book contains topics in software engineering / design / implementation / interface / documentation areas. They are all supported by solid examples, both success and failure stories. This makes it stand out among numerous books on similar topics. The author's concise and clear writting style is among the best I have seen in computer books (similar to Richard Stevens's famous series, if you have to make a comparison). The author apparently does not fail on me to make me a better Unix programmer.

The book is an good complementary to your library if you are a Unix programmer (it is also refreshing even if you do not program under Unix). And I'd recommend this book to everyone who starts to program under Unix or have programmed under Unix even for a long time.

8 great "design patterns" book for sw system architecture
Unix is the source of most of the design patterns that Raymond identifies (without, to his credit, using the _word_ "design patterns"...), but they're just as interesting if you're architecting a software system for windows, embedded hw, or cellphones. Any budding software architect should read and re-read this very instructive book.

9 All software developers MUST read this book
This is an excellent book. I especially enjoyed reading the Design chapters, which
describe how to architect software in the Unix tradition. This is indispensable reading for ALL developers, not just Unix ones.

Eric Raymond's writing is very clear, concise, transparent, and easy to read, just like the Unix coding and design styles he advocates.

This book contains almost no source code, but talks about Unix culture, tools, design & implementation methods at a much higher level. All points are followed by interesting use cases, which cover existing Unix features and applications. The book is a very comprehensive and in-depth look at the Unix world.

If you enjoyed reading this book online like me, please support the author & order a hardcopy.

10 The patterns of UNIX and how you can use them
Even for a primarily Windows programmer, this is a great book to read. He provides a great overview of the Unix design philosophy, its evolution over time, and the things that it still doesn't handle well (user-centered design). He also digs deeper into a lot of the patterns in program organization and coordination to help you choose what to build into a utility, what to expose as a library, and what to package as a set of binaries. There's even a small bit of programming advice from place to place. I'd highly recommend reading the book to at least get a sense of perspective when you're designing your next system. He's right on the mark that the Windows and UNIX worlds have a completely different philosophy on program construction, each with their own merits.

His comments about the Windows registry were a bit distressing, though -- not because they're negative, which I consider fine. Rather, it was obvious he'd never used it (comments like "there's no API for it") and it was also clear that he hadn't even bothered to research why it existed and what problems it was intended to solve. The comments were typical of what I'd expect of a Slashdot troll, but not of a bright, respectable person like ESR. I've programmed on both platforms extensively and only comment on what I have first-hand experience and knowledge of; I'd expect him to do the no less, especially as an author.

It was also curious that several times he implied unit testing == XP == agile software development. For as tuned in as he seems to be to methodolgy work, missing the forest for a single leaf is a bit embarrassing.

11 Appropriately good, considering the author
This book is written by Eric S. Raymond, who wrote ncurses and a large part of GNU Emacs, and thus one should expect a large amount of Unix and GNU bias. I don't think either are inappropriately placed, especially in a book like this. Raymond covers just about every topic that applies to the "tranditional" Unix programmer, from a historical as well as contemporary perspective, and offers a large amount of insight into each topic.

For someone moving new Unix, wishing to understand its origins and design philisophy, or for anyone developing on Unix (especially traditional development, i.e. C or C++) this book is highly applicable. The book is very readable; it's less of a technical book and more of an open discussion of past and current development practices.

If you the have the opportunity, I highly recommend you have a look at the "Origins of Unix" chapter; Raymond was there for most of Unix's history, and he recounts it vividly. This was the most entertaining and informative chapter of the book, especially for someone who is new to the Unix community. His discussions of transparency and modularity were also very practical and useful.

12 Hate to be the one to burst the proverbial bubble...
...but ESR's theory and ideology is rediculously flawed with misappropriated valuations. This is, yet another advocacy campaign for gnu/Linux, mixed in with a UNIX context. Given the purpose of the book, it's a fair assessment to label the burdening bias as filler and firewood: filler for those who really just wanted an explanation of the single-purpose, POSIX illustrated, hows and whys of UNIX programming philosophy; and firewood for those who tend to buy into slanderous hype at the whim of suggestion.

Questions: What is the title of the book? What programmatic philosophies are portrayed? How many unices are open source? Of those, how many subscribe to the same opensource mentality as gnu/Linux? Answer: zilch. Question: Then what is the relevance of such topics to the objectives of the book, as depicted in the title? Answer: fudd-ala-mode.

Aside from these intertwined distractions, and a severe Napoleonic complex against anything new or different, ESR does adequately represent the real purpose of the book, and in those efforts place value in the read.

13 A Spectacular Book
This is a really great book, 30 pages into it I had already begun raving about it to my peers. It takes the reader through years of Unix history, philosophy, application, and wisdom. It starts out slowly, explaining how an operating system can create and sustain any sort of culture. It admits the flaws in Unix and highlights it's strengths and successes. It then gets into the "Rules" of Unix Philosophy, which was something that was greatly beneficial to me in my coding life. It teaches the reader to make things modular and simple, not try to redo things that have been done before, not to be overly clever, etc.

Throughout this book the reader is given examples of some of the most basic things in the unix world, why text is so important, what "transparency" is when referring to coding, and it even includes a non-bias section reviewing some standard unix text editors. The book also gets into evaluating various languages in unix, including which is most appropriate for certain projects, which can be very helpful to someone looking to learn a programming language but who is unsure of which direction to take. A whole huge section of this book gets into the community of unix, standards, documentation, licensing, and the actual personal community.

The most thrilling part of this book for me was the History of Unix, hackers and the open srouce movement. As a history buff I always tend to be drawn to such things, and I believe he did a very good job and kept me enthralled. I also enjoyed Appendix D: Rootless Root: The Unix Koans of Master Foo, it was quite witty and amusing, as well as full of great lessons.

A wonderful computer book suitable for any sort of computer buff, even if they aren't currently working directly with Unix. It's easy to skip around this book by scanning the contents to just see what you're interested in, I really believe there is something for every computer enthusist, I am surprised a book like this hadn't been written sooner.

14 Does better at expanding your mind than herbal Zen :-)
This book is required reading for anyone involved in any form of Open Source IT. It's wisdom right up there with the The Cathedraland the Bazaar, RMS's GNU GPL, and any bantering quotes you get from Linus himself. With his book, Eric Raymond, has attempted and come amazingly close to the impossible dream of capturing the logic and natural beauty of the UNIX community/philosophy. Eric has already discussed the ramifications of UNIX/Linux's ever changing and complex structure; in both the applications, coding, and social sense . As Linus once said "The best analogy is biological diversity. You have the Linux approach that is fairly diverse and all over the map. Maybe it is not very efficient. But it works very well in the face of complexity and changing circumstances." The Art of UNIX Programming takes a very accurate overview snapshot of what UNIX means right now. Although Eric is not intensionally a "big picture" kind of guy he has painstakingly gathered all relevant information while filtering out the garbage. Every UNIX programmer secretly longs to know what Eric has so benevolently written in this book through experience. They just may not know it yet.

Of course there are some stances he takes trying too hard to go for the "big picture". Such as the already mentioned renouncement of the Object Oriented approach. But it's not a total renouncement, and the left over renouncement is for good reason on if taken on the surface. What he means is that it is better to create a small tool in a scripting language and then do the Object Orientation through pipes for example: ps -A | grep bash | less. That's like calling upon objects less(grep(ps(A), "bash")), as functions; whatever you wanna call it, if it has encapsulation inheritance polymorphism then it's OO by definition. Eric would like to live in a world with many small tools (or libraries if you will) that when combined can create something much larger in scope. The argument is akin to something like an automotive factory assembly line. However, when taken to far it's akin to a one hundred thousand monkeys writing on one hundred thousand typewriters... and you know the rest and that'll never happen. I guess it all depends on if your building off of an axle of modularity or monkeys.

Anyway, buy this book and you'll have no end of geeky philosophy to argue about.

15 More books like this need to be written
"The Art of UNIX Programming" (TAOUP) is a unique book, since it deals with "UNIX" engineering principles. ("UNIX" means the original OS as well as derivatives and relatives.) Rather than discuss the filesystem, commands, or services, TAOUP explains history, culture, and rationale. I found the book enlightening and easy to read and recommend it to all UNIX users.

Several reviewers critique author Eric Raymond's assessments of programming languages and the Windows OS family. As a security engineer I see Windows continue to fail miserably, so much so that I'm beginning to agree that Windows cannot be secured. (Almost one year ago I criticized Bellovin et al for the same judgment, but now I tend to agree.) I would be surprised if a real Windows advocate reviewed and contributed to drafts of TAOUP, as a few strategic pro-Windows points might have made ESR's other arguments stronger. A second way to strengthen the anti-Windows stance would be more technical discussion of Windows flaws. The devastating "shatter" flaws of 2002 merit no more than a footnote on page 69, but could have a been a whole section unto themselves.

Regarding languages and OS comparisons, at this early point in my career I fit the "fool" category of p. 507. I leave it to more experienced developers to debate programming language virtues. It seems the author is not as current on language developments as his critics, which is regrettable but understandable given TAOUP's scope. I personally questioned the repeated invocation of Emacs Lisp. I found ESR's recommendation to employ interpreted languages useful and plan to take a closer look at Python. I question ESR's claim on p. 382 that GCC is so powerful that "there is effectively no proprietary UNIX compiler market left," when Sun's compiler for Solaris seems to outperform GCC.

I found histories of "UNIX vs. UNIX" and "UNIX vs the world" very informative. TAOUP presents concise explanations of licensing, RFC creation, and UNIX philosophy. I was happy to see that an open source project to which I contribute (Sguil) met many UNIX design criteria, like text-based communication between small collaborating daemons. I plan to follow TAOUP's recommendations for documentation so helpfully discussed in chapter 18 when I release the next set of Sguil guides.

TAOUP offers numerous priceless quotes from UNIX pioneers, but ESR himself offers my favorite: "Open source is what happens when code reuse gets a flag and an army." I hope UNIX advocates everywhere carry TAOUP into battle against their proprietary, monopolistic OS foes. With a few more nods to the enemy and a more balanced comparison of languages, TAOUP will be unbeatable.

16 Timeless Technology
OVERVIEW
--
OK- so I'm a relatively young developer, and my 'professional' programming experience doesn't start until the mid-late 90s. So I guess that means I've grown up in what's manifest as Open Source. Open Source and UNIX is all around me, and has become the richest and most open creative community I've ever been a part of. I can hardly fathom, any sustainable software world outside of Open Source, open standards, and open process. I love Open Source, every aspect of it.

The Art of UNIX Programming has given me an understanding of where this all came from, the rich traditions and working process that _is_ UNIX, as well as the people that _are_ UNIX. ESR (as he's known in the Open Source communities) maintains an extremely forceful and open vibe throughout.
It is noteworthy that ESR is giving a fairly one-sided view of the history of computing, as he's completely focused on UNIX, and Open Source- and isn't afraid to poke at other processes and systems as he moves along, but it's clear that he's really passionate about UNIX. He's not preaching in this text, he's clearly addressing the Open Source UNIX hackers out there, and his directness seems to have made some enemies.
I tend to like it when one has enough guts to put their neck on the line to communicate what they care about- and ironically, ESR's tone, however one-sided, is biased towards Open Source in a sort of evolutionary selection process, in opposition to a human-forced set of rules that guide technologies; so his one-sided fervor is quite an easy pill for me to swallow.

Noteworthy, this book will really tick off anyone who's not comfortable nodding to a periodic MS and Proprietary IT-establishment slam here and there. It's also got some stiff words for Object Oriented programming- but speaking as a programmer who uses Object Oriented languages and systems, I actually feel he addresses some of the design weaknesses that I have experienced (mostly in things that re-invent the computing wheel in confusing ways).

If one can get beyond that, there's TONS of wisdom in here that EAR shares, from one of the oldest and evolved systems in computing, UNIX.

ABOUT THIS BOOK
--
Right off the bat, I was hooked, as Eric S. Raymond is one of the first people I've heard in Computing to refer to one of my favorite authors, Christopher Alexander . To me, this either says that like many professional communities, IT/CS doesn't pay much attention outside of itself, or I gotta go around the block a few more times before I state such things- (or perhaps a mix of both ).

From here, I'll divide the book into 2 parts, People/History, and Process/History. ESR glides through a great history of the People and Systems that have influenced contemporary UNIX systems, and then proceeds to dive into the vast accumulated systems and process that an operating system with 30+ years of history has generated.

Re. People:
UNIX roots are way more punk-rock than I could have ever imagined. Reading the history and personal accounts in The Art of UNIX Programming was to me, like going over my family history with a grandparent. To be honest, I had NO idea how much I had in common socially, IT-politically, and in spirit, with the original creators of UNIX. I hate to get all spooky n' stuff here, but it was all like some weird conformation of things I knew through osmosis- by using UNIXes. That's about the best way I can explain it. Not that it created some hierarchy of rock-stars, but it brought me closer to what I consider to be like family. ESR brings in some of the original creators of UNIX to speak on given topics throughout the book, and discusses some of the cultural divisions in UNIX culture.

Re. Process:
Osmosis. Good design breeds more good design, and the rest of the book delves into the myriad of lessons in good design which have come out of UNIX.
The process sections of this book didn't really preach the legalism of a manifesto, but instead showed the roots of what's influenced UNIX today, and how that manifests in what I make daily. The principles discussed come from the vast discourse of software engineering on, and for, UNIX systems- and one of the best principles I took from this book are that the systems that have lived the longest lives, have done so because of a reason.
The process part of book have given me a whole new level of respect for a lot of developers and projects which I simply didn't understand before, or took for granted.

CONCLUSION
--
This book was great fun for me; it's big-picture view made me realize I'm totally a kid with UNIX, and documented guiding principles that I interact with every day.
The book would be very accessible for non-technical readers, as advertised. This book would be a good read for an Architect, or Urban planner, as well as most anyone in a given Design-oriented field- though it does require some basic understanding of computing to get into. I believe the crossovers in UNIX practice and other fields are astounding (and I'd LOVE to read an 'outsider' review!).
Anyone in or around computing in any way would get SOMETHING good out of this book, and 'The Art of UNIX Programming' is a must-have for anyone who works with, and loves, UNIX.

.ike

17 Autohagiography with some programming tips
The writing style of this book tends to hurt the reading experience, as Raymond trumpets his own minor achievments in the free software community. The work feels like it needed one more rewrite before being released to the public: some related sources Raymond hadn't yet read at the time of writing, and some of his advice gets repetitive.

The exposition itself is not up to par with The Elements of Programming Style. Raymond tries to give a list of programming rules or principles to follow, but it reads more like a list of slogans that should be taken as axioms. While The Elements of Programming Style itself had a list of rules, the rules were well woven with each other, well defended, and they were used as a means of conveying a larger story. In Raymond's case, he relies upon the slogans in absence of such a story.

Thus, the book ends up more like a list of random unrelated tips. Some very profound, like his writings on threads (which he acknowleges Mark M. Miller for his help). Others are very shallow and pointless in a book that supposes to call itself about "Art." Some of the pieces appear only to function to attack Windows, and sometimes the information about Windows is embarassingly inaccurate.

One final criticism is that Raymond does not understand object-oriented programming very well and misses the point in several cases. You just need to see the popularity of Python, Java, C# (Mono), OO Perl and C++ in the Linux world to see that Raymond is off base calling OO a failed experiment. In fact, with almost any matter of opinion in the book you can feel Raymond's bias and be hit in the face with misinformation or dull false dilemmas.

However, given this book's many flaws, I rate this 3 stars instead of 2 stars because it also has valuable information from the many contributors, some of them Gods in the Unix world. These contributors often even disagree with Raymond, or point out other interesting tidbits. For these tips alone, it is worth checking out this book, though I would not recommend you buy it.

To get the true Unix programming philosophy, I recommend Software Tools, by Kernighan and Plauger. It's somewhat dated, and I recommend the Ratfor version of it, but that single book has became very influencial as I grow as a Unix programmer.

18 Highly informative and readable, though very biased
Raymond does a good job of explaining the philosophy driving the Unix-style of programming. Coming from a background programming Windows, I always thought of the Unix approach (lots of abbreviated command-line utilities, mini-languages, pipes, semi-unstructured text-based process integration) as down-right primitive. However, after reading this book, I've started to understand the philosophy (and the practical reasons) for adopting this approach. I'd definitely recommend this book especially to newbie programmers from the Windows or Mac (pre-OS X) worlds. That said, I do have some criticisms:

One of the problems with this book is the overly partisan tone it takes - one gets the impression that absolutely nothing Microsoft has ever done is of value, but the other major desktop PC OSes (Apple, Linux) represent different forms of perfection. (At home, I run Mac OSX, RedHat Linux and Windows, and have a reasonable sense of their relative strengths and weaknesses.)

So, be warned: Art of Unix Programming paints a one sided picture. The author is a well-known figure in the open source community, one of its fiercest advocates, and one of Microsoft's most vocal critics, so it might seem to strange to wish for less anti-Microsoft spin from this source. After all, the Raymond brand certainly carries with it an obligatory expectation of Windows-bashing, doesn't it?

One of the only Windows design decision which Raymond doesn't condemn is the (now discontinued) .ini file format. Even the thorough-going support for object-orientation in Windows is given short-shrift: after explaining the many horrors of object-oriented programming (according to Raymond), Unix-programmers are praised as "tend[ing] to share an instinctive sense of these problems." This section (http://www.faqs.org/docs/artu/unix_and_oo.html) is particularly illustrative of the one-sided approach that Raymond takes.

Art of Unix Programming is really an excellent and informative book which could have been substantially better with a little balanced discussion. I found myself constantly second-guessing the author: Is he arguing such-and-such a point on the merits or because he simply loves UNIX & hates Microsoft so much? While the book does a great job of articulating and illustrating the UNIX idiom, it's a shame that the reading experience is marred by mistrust. If he hadn't been so blindly anti-Microsoft, we'd be able to more confidently rely on his conclusions, and the text would be not merely highly informative (as it is), but definitive (as it is not). Four stars, therefore, instead of five.

PS: You can find this book on-line with Google - no charge.

19 Indispensable guide to Unix history, culture and principles
This is a wonderful book. As far as I know, it is one of a kind in its scope and concerns. It put many aspects of computing in perspective for me and deepened my appreciation for Unix, as a technology, social phenomenon...and attitude. It is instructive and useful to compare and contrast the outlook presented in this book with those of major corporate players, such as IBM and Microsoft.

20 a brilliant explanation of the success of Unix & friends
This is an excellent explanation of how & why Unix and the ideas behind it have endured so well over 3 decades, while other systems have gone the way of the dinosaurs.

I've been in the Unix field on and off for 20 years and was amazed at how much I learnt from this book. It makNot only that, butes so many things clear that were unconscious to me and probably many others.

It also explains how to use these ideas to improve software projects, whether under Unix, Open Source, or even proprietary systems. With the current Linux explosion, it's great to find out how to use the same principles for other projects.

I believe that every programmer, whether working with Unix, Windows or other systems, should read this book at least once.

21 To Learn the Philosophy of OS(UNIX) Software Architecture
Others have found that the INTP Myers-Briggs Type Indicator is the preferred personality type for (software) architecting team membership. After I wondered how to be more "philosophical", this book helped by teaching about the Unix Zen-like philosophy. If you think this way, you should be able to improve a design.

Chapter 3 "Contracts: Comparing the Unix Philosophy with Others" starts with this quote from a Dilbert newsletter, "If you have any trouble sounding condescending, find a Unix user to show you how it's done." Nevertheless, I am more likely to be less critical and more philosophical about designs after learning about the OS designs of VMS, MacOS, OS/2, Windows NT, BeOS, MVS, VM/CMS, and Linux.

The last chapter titled "Futures: Dangers and Opportunities" summarizes the philosophical differences between operating system design in the past and in the present with Linux. By the time I got to this last chapter, I see that this book is a real eye opener and you will think "philosophically" about software designs. Understanding history does help. The next generation is thinking about usability along with the open design patterns of the OS. This is paradigm shift for Unix and Windows gurus.

Besides learning about how to think philosophically, this book is a gold mine to a software engineer. For example, chapter 2 "Basics of the Unix Philosophy" covers 17 rules on design that every software engineer needs. Additionally, chapter 16 "Reuse: On Not Reinventing the Wheel" is a hoot. Today, some professors do grade on code readability, style, and program documentation.

Chapter 14 "Languages: To C or Not To C?" is another learning experience on language choice. I cannot help but wonder if the authors are not Zen-like enough because of their love of their offspring C, when today there is a growing community using Java for embedded Linux software, because of its portability, improved memory management, and eliminated pointer security problems. Platform neutral language and OS.

Chapter 19 "Open Source: Programming in the New Unix Community", should be required reading for a software engineer. We need to learn about the open source software development process.

If there were only time, this book would make an excellent addition to a computer science OS or software engineering course. Software architects need this book. The Masters have a done a great job by contributing to this.

22 A Great Read
To extend the author's idea:

Any book should be useful in the expected way, but a truly great book lends itself to uses you never expected.

This is quite appropriate for the Art of Unix Programming. This book is high level, built on philosophies and practices instead of the volatile low level techniques. It not only has changed the way I view programming, it has changed many of my Covey scripts. (See Seven Habits for further informaiton.)

23 The philosophy behind the code
The Art of UNIX Programming by Eric S. Raymond, contains over 30 years software engineering wisdom. In addition to Raymond?s own experience, the book also incorporates knowledge from thirteen UNIX pioneers including Ken Thompson (the creator of UNIX) and David Korn (creator of the korn shell). Raymond?s book tells about the philosophy, design, tools, culture, and traditions that make up UNIX. Raymond shows how these are being carried forward today in both the open-source movement and Linux.

Personally, I rather enjoyed reading this book because it's not just another book that teaches you how to use a particular programming language. This book teaches you how to design software, teaching you the philosophy behind UNIX and contains some of the history hacker lore that made UNIX what it is today.

Unlike most programming books I have read this book uses case studies to prove a point rather then tailored examples. The case studies use real, pre-existing pieces of open-source software that are in use every day (including Kmail, The Gimp, Audacity and many others). Through these case studies Eric demonstrates how to apply the book's wisdom in building software that not only adheres to the UNIX philosophy but software that is more portable, more reusable, and longer lived.

24 Great, sprawling read
Focus on the strengths of the Unix philosophy. Helps experienced people put "things they've always known" into words.

25 Nothing About Everything or Everything About Nothing?
Take a look at the online version available at http://catb.org/~esr/writings/taoup/html/ and think twice before buying this book. Unless you are a complete newcomer to Unix programming, TAOUP will be useless. The first part, "Design" covers the culture of Unix, and may be useful, but the rest of the text lacks the necessary depth. Real Unix programming books, like Stevens' one are much better.

26 Indispensable addition to a UNIX guru's bookshelf
Eric S. Raymond has achieved a wide reputation; as an advocate of Open Source (as opposed to Free Software), as a writer of manifestos (The Cathedral and The Bazaar), as the original maintainer of The Jargon File, and even as a programmer (Fetchmail, and recently Bogofilter). His advocacy has been sometimes at the expense of Richard M. Stallman, which has not always redounded to Raymond's benefit.

With The Art of UNIX Programming, Raymond moves into a new area (for him), the software engineering guide. This is a relatively obscure genre comprising a relatively small number of books, including to my way of defining it, Modern Operating Systems (Tanenbaum), The Practice of Programming (aka "The Wiener Dog Book", by Kernighan and Pike), The Magic Garden Explained (currently selling for $300 used!!), and a few others.
These books share the common goal of imparting maximum accumulated wisdom to those best positioned to take advantage of it. These books target the folks who live, eat, and breathe software.

While not a cookbook, The Art of UNIX Programming does provide an extensive set of rule-of-thumb and the-right-way recommendations for designing interfaces and for generally maintaining a UNIX style approach to implementation. Examples are presented of interfaces to protocols, and to client software, mixing the discussion of frontends and backends in a unified context that works very well.

Raymond makes no bones about being an active critic of the various incarnations of Microsoft Windows. He makes strong arguments against the sanity of the windows development model, and supports those arguments very well. Perhaps it is a reflection of my own prejudice that I can support this while being offended by his treatment of Richard Stallman. But then again, Windows really sucks.

A pet peeve of mine is unneccesary bashing of the Tcl programming language. Raymond takes a far greater number of pokes at Perl than at Tcl, but does nevertheless propagate the myth that Tcl's namespace facility is in some way a limiting factor to scalability of Tcl programs. This is, of course, ridiculous, and it is unfortunate that nobody capable of correcting this mistake was in the right place at the right time to nix it. Not only does Tcl have a well implemented namespace facility, but it has a brilliant core socket abstraction, and most importantly, an efficient event loop, similar to the one that Raymond lauds in X (hence it's ability to manage complex Tk programs).

I find considerable evidence within the text of The Art of UNIX Programming suggesting that the original title may have been The Zen of UNIX Programming, or maybe Zen and The Art of UNIX Programming,. I think the references to Zen in the text would seem less out of the blue if the title had been so, anyway. A more on-the-ball editor could have made a better job of it.

In spite of many things that I have written here that seem critical of the book, I recommend The Art of UNIX Programming highly. I have given several copies to friends, and I have recommended it as a software design and implementation handbook at work. I recommend this book to anyone working in a UNIX environment in any capacity, but to coders especially. Raymonds observations on threads are worth the price of the book, to anyone willing to heed the warning.

27 Good introdution but limited.
This book is about programing for the UNIX culture. And has many good sections.
In section 1.6 there is a list of design rules for writing UNIX programs. But I feel that these design rules are mainly for writing small programs or tools. I don't think that the rules are good enought to scale to large system. A problem with the book in general.
There is a setion comparing UNIX to other operating system. I not sure the need for this comparisons. The OS is not always the choice of the programer. I find this section just marketing.
The sections on data formats and languages comparisons are very good. And are back up with good case studies.
Also the section on writing doc. for UNIX programs is very good.
In all this would be a good introduction new to UNIX and programing.

28 Filled with good stuff
By reading this book, one can truly realize the greatness of the Unix operating system and all of its glory. How it has revolutionized the software and more specifically the Operating System industry over and over again for the past 30+ years.
This book has four parts, and each part is packed with useful information... The first part talks about the philosophy, the history and background of Unix. It's a very easy read and it familiarizes the reader the background of Unix and what will be covered in the rest of the book. Basic rules that Unix was based upon and their explanations are to me, the highlight of the first section.

Part 2, focuses on the various design rules and philosophies that were covered in part 1.
It is packed with small, easy to read and understand case studies that explain the design philosophy that was just explained. It is very interesting to see that some of what we call "best practices" today have been around for years and years in the Unix community and have been perfected thru out the years. Very valuable to any software architect. It will give you some ideas what has been done and what not to do when you are designing a piece of software - b/c the chances are that it has been implemented in Unix before.

Part 3 goes into a great depth trying to explain the various options programmers have when developing for Unix.
Considering that an entire volume can be dedicated to this section, the author does a great job in explaining the various options for developers. Keeping the philosophies mentioned in part I, the author conveys the pros and the cons of various programming languages, scripting languages, took kits, etc...

Part 4 covers odds and ends of this topic. It gives you tips on how to work with the Open Source Community and what you need to do if you want release code into the open source community. The tips are also very valuable even if you are developing software for your company... One of my favorite sections in part 4 was when the author talks about the various licenses and their differences and how to choose one. With all the lawsuits surrounding the Unix community, it's good for every developer to know what options are available out there.

29 Finally, Unix culture laid bare.
I'm glad someone finally wrote _The Art of Unix Programming_, and particularly pleased that it was one of the Unix community's greybeards who did it. I earned my computer science degree a decade ago and have spent the time since wondering why no one has ever written anything like Eric Raymond just did. Excellent.