The Art of UNIX Programming

As someone who's programmed on Unix for many years, I've known about esr for some time, and probably should thank him for being part of a chorus that encouraged me to learn things like Lisp. That said, my honest opinion of this book is that it's a waste of paper and approximately the quality of a typical esr blog post.First of all, this book is not really about Unix programming. A full half of it is dedicated to rehashing the Unix philosophy, history, and community. Yes, these topics should come up, but at some point I want to read about Unix programming, which is why I am reading a book with that phrase in the title. None of this stuff has anything to do with programming, and is just as applicable to end users.The other half is supposedly programming related, but upon closer inspection, mostly isn't. Major topics include things like tools, config file formats, and a lot of general stuff that applies in non-Unix development too (like VCS and network protocols). Where's the system programming tips, POSIX standards, standard libraries, ioctl, BSD sockets, security considerations, and any number of hundreds of other things anyone who's programmed on a Unix-variant encounters? Yes, the book claims to not want to talk about these things, but guess what, that's what Unix programming is all about.Languages (you know, the thing you actually program in) are completely glossed over, except to just list a few common ones. Half of the ones mentioned are so portable, that programmers in them can ignore OS peculiarities the vast majority of the time (Java, Python, Emacs Lisp). C, C++, and shell are very tightly coupled to Unix, and much could have been said here, but isn't. Instead of code, we're treated to reams of config file examples and other filler.The various aspects of The Unix Way could have been stated in a single chapter. Someone interested in becoming a Unix programmer needs to know where to go to find documentation, what development resources he has available, and other practical things. An MS programmer reading this book would be just as clueless on how to start programming on Unix as before. Go pick up Advanced Programming in the UNIX Environment if you want to learn this subject.

I got a great deal out of this book - I switched to Linux fairly recently, and had reached the "state of maximum confusion."(I hope.)By that I mean I had learned quit a lot, but hadn't been able to pull it all together. This book went a long way toward doing so. The sections on Design and Implementation could be expanded to a good book, they gave me an understanding of Linux, what to look for in software for Linux, and how to approach programming for Linux.Design and Implementation both used case studies of specific packages, some of which I now use. I only wish this careful dissection was available for more software.The other two sections, Context and Community would also make up a good free-standing book. They explains how Unix became what it is (Context) and where it is going now (Community).Any way, great book, and I would give it 10 stars for two books if that ever happen.

Eric S. Raymond is a controversial open source developer and evangelist. The true is that he has a good points and ideias of how to develop using the unix pratices (eg. the practice of separation and program specialization).I love unix (any flavor), it is by far the best operating system for a wise developers. The advice of Eric really makes sense for someone used to work with unix, and I put a lot of his advice to good use.I recommend this book to an intermediate/advance unix programmer/analyst.

The author does a great job explaining the Unix tradition and where it came from. This book is filled with design considerations and high level concepts related to programming techniques. It gives a clear insight into what went in one's mind when designing many of the programs that are so common to Unix.I think you will enjoy this book if you have had basic exposure to Unix (even as just a regular user), and some basic exposure to programming.

This at least is the overarching message conveyed both directly and incidentally throughout Raymond's book. Unix in the concrete, non-abstraced sense has died and been replaced in practice by Linux and with the former solidly displaced from the market we can apparently begin to take to the bold liberty of refering to Linux interchangably with Unix's name. From the title the book advertises itself to be about Unix but from the opening chapters documenting the history and progression of Unix there is a clear effort to re-cast the decades long history and family tree of Unix operating systems into a footnote to the modern re-implementation in Linux and even the overall open-source movement at large. All of which the various originating UNIX architects solicited for in-line commentary seem to be conspicuously silent about. This is impressively maintained through the rest of the book without any substantial mention of BSD-derived operating systems or OSX beyond the opening of the text. Sadly, for what praises can be offered for this book, it's notable and distracting that Raymond suffers from a stark habit of inserting a number of personal biases and pet causes into his prose, as this book actually does otherwise serve a novel and admirable use in the valuable documentation of history and culture in passing eras of computing and development.The close-knit communal spirit of timesharing on minicomputers in Bell Labs is seized on as a faint archetype of modern distributed OSS development while Ritchie, Thompson and the rest are curiously painted as disheveled and counter-cultural "hippies" "flipping a finger at the system", never mind these were the same hippies who would stay along for the ride on the side of Ma Bell and SVRx against the Berkeley Academia as the Unix market cannibalized itself in the late 80's. While nonetheless engrossing in its own right, there's some degree of romanticism and embelishment laced in the presentation of Unix history here, and unsurprisingly it tends to err quite clearly on the side of presenting the the earliest days of Unix as a directed progression toward the wider quasi-social movement of collaborative development and open-source software. This kind of disquieting historical reinterpetation and editorialization continues throughout in places both trivial and not: Raymond, for instance, clearly has a low personal opinion of Richard Stallman's attempted infusion of moral context into the realm of Free software development and regrettably manifests this, rightly or wrongly, in the unsubstantiated assertion that Stallman has been popularly marginalized, thereby imposing his personally-held disdain for FSF priniples on OSS developers at large. He can do this, you see, because he is authoring history.Other varying idiosyncracies crop up: anywhere Perl is mentioned, Python (Eric's personal favorite scripting language) will appear by it's side. Emacs Lisp is inexplicably offered alongside established systems programming and RAD languages as a choice for a general-purpose programming language. And on the topic of Emacs, a partisan argument for rationalizing Emacs's notorious feature creep is presented in the form of describing it as a general extensible scripting framework in harmony with the Unix philosophy of modularity, rather than a conspicuously bloated but still useful text editor. This of course, is accompanied by apparently obligatory potshots taken at vi and Vim. It's less alarming that he'd reasonably arrive at a spirited opinion of this sort of thing than that minor personal convictions and editor war ammunation essays such as these would find their way into a text purporting to immortalize and document the Unix culture for all to refer to.The less inflammatory parts of the book can laregly be summarized as case studies of the Unix spirit of design, effectively all of which can be distilled at some level as interpretations of the general KISS philosophy, which for the uninitiated basically translate to explicit warnings against overengineering. I'm suspicious of how much of this is simultaneously revelatory and actionable, but I suppose it's easy for ideas like these to be lost in the modern age of professional software development. Moreover, as this book explicitly aims to convey unquantifiable ideas and culture it's difficult to rate the book in terms of the knowledge imparted; it's a sometimes disjointed accumulation of essays on a wide range of topics spanning Unix history, various shell tools, predictable FOSS cheerleading, licenses and languages. And despite the above criticisms, much of the book actually makes for interesting reading despite the author's clear self-insertion into much of the book; it all actually makes for decent light reading even if the overall value is indeterminate.But to end in the same manner as I believe other reviewers have, it is overall something to be taken with a grain of salt.