Become a fan of Slashdot on Facebook


Forgot your password?
Unix Books Media Operating Systems Software Book Reviews

Think Unix 51

Jon Lasser is the author of ThinkUnix a new learning UNIX/how-to. While Danny Yee of dannyreviews actually wrote the review, I've read the book as well. It's good -- it's different from other learning Unix books because he really wants you to learn the concepts behind Unix -- to grok it.
author Jon Lasser
pages 294
publisher Que 2000
rating 8
reviewer Danny Yee
ISBN 0-7897-2376-x
summary Rather than trying to be a detailed guide to a particular system, a comprehensive reference work, or a source of answers to particular problems, Lasser tries to teach the fundamental concepts of Unix and the Unix way of thinking.


In a world full of volumes like Linux: The Complete Reference, Debian GNU/Linux 2.1 Unleashed, Corel Linux for Dummies and so forth, Lasser's Think Unix is a breath of fresh air. Rather than trying to be a detailed guide to a particular system, a comprehensive reference work, or a source of answers to particular problems, Lasser tries to teach the fundamental concepts of Unix and the Unix way of thinking. He also captures something of the way in which Unix is a way of life and a culture, not just an operating system, with a good leavening of humour, history, and hackish lore. One consequence of this approach is that Think Unix will date far less quickly than most operating system books. I recommend it to computer science students, techies coming from non-Unix backgrounds, or anyone more interested in understanding the underlying ideas of Unix than solving particular problems.

Lasser starts with a chapter on documentation, explaining how to use "man" to read manual entries and touching on other forms of documentation. He then introduces the building blocks of Unix - files and processes and redirection and pipes. A brief look at TCP/IP networking, showing how to interact directly with some common network services using telnet, is followed by an introduction to vi and sed and basic regular expressions. Four chapters then deal with shell scripting in more detail, touching on differences between shells, variables and quoting, control structures, and aliases, functions, and scripts. A quick look at X explains its general design, something of the variety of window managers and desktops available, and basic configuration of startup, resources, and fonts.

Obviously a lot is left out of this (there is nothing about system administration, for example), but it provides solid foundations for further learning. And a number of topics sneak in "in passing": a mention of ssh (and associated legal issues) and a little bit about termcap and terminfo, among other things. Some practice problems are included, simple exercises to test understanding and help learning; answers to these are provided in the appendices, along with a short glossary (which includes pointers to other resources).

Think Unix has an unfortunate number of typos, including a few in code examples. And there are a few things I might have done differently (I'd have ditched most of the grainy greyscale half-page screenshots of different window managers and desktop environments, for example). Overall, however, it's a great book and the biggest problem it poses me is working out which of my "clueful but not Unix-literate" friends to pass my review copy on to.

Purchase this book at ThinkGeek.

A book review by Danny Yee <>
Reviews of more than five hundred other books: Subjects | Titles | Authors | Latest

This discussion has been archived. No new comments can be posted.

Think Unix

Comments Filter:
  • by Anonymous Coward on Monday September 18, 2000 @05:25AM (#771799)
    There are two ways of looking at how to bridge the gulf between users and a computer system (HW and/or SW). There's the Apple way, which involves doing a lot of work to hide or automate or make palatable system details. This can work very well, but it often has the dreaded "dumbing down" effect that makes a system harder to customize or even understand below the UI level.

    The other approach is the Unix one, which says that it's the user's responsibility to learn the system, warts and all. This is exactly the mentality that created the "Unix wizard" syndrome in the first place (people have to work hard to learn how to use the system effectively, and then they don't want it simplified for others, which would only devalue their accomplishment), and sadly, there seems to be little going on in the Linux world to counteract that.

    In the short run, books like the one reviewed here are probably a good thing, but I would love to see more serious work being done to make them less needed.

  • "The other approach is the Unix one, which says that it's the user's responsibility to learn the system, warts and all. This is exactly the mentality that created the "Unix wizard" syndrome in the first place (people have to work hard to learn how to use the system effectively, and then they don't want it simplified for others, which would only devalue their accomplishment), and sadly, there seems to be little going on in the Linux world to counteract that."

    If there is so little going on in the Linux world to counteract the Unix wizard mentality, what do you call KDE and GNOME? Both projects are about making the Unix desktop easier to use, and while neither have fully succeeded on that goal yet, both projects are going strong and are high-profile in the Linux world, hardly what I'd call "little going on".
  • by Tony ( 765 ) on Monday September 18, 2000 @07:08AM (#771801) Journal
    It's just particular about its friends.

    - Tony "Yes, it's paraphrased" Taylor
  • FYI: The llama book is indeed an O'Reilly book (Learning Perl)

    As far as I know, it is one of only a handful of O'Reilly books more commonly referred to by their colophonic companion animal than by their official title. The others being the Camel book (Programming Perl) and the bat book (Sendmail). There may be a couple of others, but those three are the only ones I know of that fit that description

  • Like in most arguements, there is a mid point and see both points. I think the *nixes in general could be easier to learn. Could someone please re-write my damn man pages please? I understand they all sound like they were written by pissed off programmers venting their hatred for the end-user as they pretended to explain the functionality. Man pages are good for simple commands but try figuring out how to do something complex with awk and sed from the man page. No way! That is why O'Reilly has a whole book on awk and sed.

    Anyway, I can also see the other side of the point though. Once you know one *nix you really are able to adjust quickly. Honestly, I kind of like working from my Sparc Ultra 5. Solaris is damn stable and helixcode runs really smooth on it. The terminology is a little different and really the only thing else that would freak newbie out about my Sparc is the placement of directories. The different *nixes are not that different. People seem to be very frightened about moving between them. I think that is rather odd.

  • You luserish stupid!
    That command will, on a Linux system, only erase every file/directory in the root beginning wiuth a character ASCIIbeticaly prior to 'p'. After doing so, it will get stuck into an endless loop in /proc. The reason thereof is left as an exercise for the reader.
    Next time you try to educate users, please write commands that at least _terminates_, that is, either returns or core-dumps.
  • How about some errata for the errata? :)

    [ . . . ]

    These are all fixed. Thank you for reporting the problems.

  • Try using a real UNIX for a couple of months, then tell me Linux is the same.

    Well, I'm a professional Unix sysadmin (And the author of the book. :-)). We're a Solaris/IRIX/Linux shop. Linux is the same. Or at least as much as either Solaris or Irix is.

    We've moved many of our central AFS servers to Linux from Irix because Linux is much more stable. (Solaris does well too as an AFS fileserver, but why pay more when you don't get more?)

    We've moved most of our labs from Irix boxes to Linux boxes. We're down to two labs with Irix boxes, which will probably be replaced in the next year or so with Linux boxes and decent 3D cards.

    About one-third to one-quarter of our central servers (for around 20,000 active accounts) are Linux boxes.

    Linux is Unix.

  • Too bad, since X Windows is not an integral part of Unix. I was about to recommend this book to a couple of MacOS X newbies, but this serious flaw made me reconsider.

    The book has eleven chapter. The last two chapters are about X. X is a major Unix subsystem that most people have significant problems with, so it needed to be covered.

    Put another way, the book is has 242 pages of main text. Pages 1 through 196 don't have a damned thing to do with X; pages 197-242 are about X. Nothing before page 197 cares whether or not you have X, so not having X shouldn't stop anyone from getting through the majority of the book..

  • by disappear ( 21915 ) on Monday September 18, 2000 @07:17AM (#771808) Homepage

    Hey, I'm the author of the book. This is a fair criticism, but...:

    1. There's an errata for the book. It is, as far as I'm aware, entirely complete and up-to-date. It's over here [] (the address is listed in the book, yes). You can determine how many of these have any impact whatsoever on the content.
    2. There are two typos I know of (one of which Danny Yee reported, and both of which are in the errata) in 'code examples' (that is, anything that looks like a transcript of a session). One of those is in the output of a command (the wrong quotes are displayed as output), and the other is a case where the point is that a certain thing doesn't work. (In talking about $0-$9, I show that $10 doesn't work. Only it was shown as 10 rather than $10 in the example.) This one should be clear from the context, but the point is that it doesn't work anyway.
    3. I am anal-retentive. But things get messed up in the editing phase, as documents are passed back and forth among half a dozen people and file formats change, etc.
    4. It's also a first printing. Some stuff will be fixed in the second printing. Everything will be fixed in the third printing. The second edition of the Llama book's first printing was horrendous. Especially the code examples.
    Correctness is important to me. But I'd have to say that it's pretty darned good. Check the errata and decide for yourself before making a comment like this, please.
  • Actually, I was never slapped. Just modded into oblivion. :-)

    I could never get StarCraft to function under WINE. I couldn't even get it to load, even if I pointed it at my existing windows directory. I could never get the fake registry to work. WINE really needs to be able to create all the things it needs to work on it's own, if it doesn't find them. That, or we need a good configuration tool that will do this.... Hmm.... Think I've found my next project...

    Fawking Trolls! []
  • Perhaps you could mail me your registry? I'm at the address above, or - I'd sure appriciate the help. If I can get StarCraft running, I'm 1/2 way to getting rid of windows.

    Fawking Trolls! []
  • I've been playing with Linux/Unix/BSD since 1994, and am mostly self taught. Most of my friends think I'm a guru, but I have to tell you, I haven't even earned my benie yet - much less a wizards hat. The system can be so complex, and user hostile at times, that it defy's description. While I'm sure it will never be as easy to use as say DOS 4.0 was, I'm hopeful that one day, it won't be so needlessly complex! That, and we need to loose the attitude "It was hard for me to learn, so bend over and take it like a man!" that we get from the veterens.

    Fawking Trolls! []
  • Yes, sorry. I should have made that clear. I have no real use for X, as most of the games I like to play (when I have time) don't run yet on X. If StarCraft and Diablo II would run under wine, I'd be alright - but they don't. Also, I've noticed that the client doesn't work as well in the GUI as it does in CLI mode on Linux. My old system (Athlon 500 128M ram) which was Slackware 4.0.0 got 1.2Mkeys/sec CLI but only 350~Kkeys/Sec under X. The performance hit was totally unacceptable. Maybe X 4.0.0 will be loads better, but somehow I doubt this. I don't need a GUI to get work done - I'm a lan/wan specialist for DaimlerChrysler. I use PING more than anything else these days, mainly to find IP addresses that contractors steal without permission. One quick DOS on that IP and suddenly I get a call for support. "Hey, I can't see the file server anymore!" "Really? What's your IP address, and who asigned it to you?" He he he.

    From the intuitive standpoint, I don't think X is anywhere near up to being as good as it's competition, HOWEVER I think it's strength lies in it's flexability. I was showing the PFS guy at work all the different GUI's that come with Mandrake 7.1 and he was astonished. Too bad it slows the system down so bad. But again, perhaps this is my fault - if it wasn't so hard to learn how to configure things, maybe I could get X to run better. I dunno. I'm going to buy this book (I'm such a sucker for books) and see if it teaches me anything I don't already know.

    Fawking Trolls! []
  • by Vladinator ( 29743 ) on Monday September 18, 2000 @05:40AM (#771813) Homepage Journal
    Bravo! I couldn't agree more. BTW: Another good book on the topic is AEleen Frich's "Essential System Administration" from ORA. It's not the MOST user friendly book, but it's the best one I've read yet. It helped me MUCH, but we STLL need something like "Unix in a Nutshell" translated more into english.

    Fawking Trolls! []
  • Sigh. The point in a way is that most things from M$ work about the same - not so in Linux. I've found TAR to be user hostile at times. Now that I understand TAR, it isn't anymore - you lack the perspective of struggling to learn something that is initially difficult. You're "There" You have "Arrived" and you "Grok" it. As a result, you don't understand why others have a hard time with it. It's no different than when I was studying medicine in the service - AFTER I had been to school, I always wondered why people had a hard time "getting it" so to speak. I've had good friends and close realitives give me that "deer in the headlights" stare when I talk computers with them - It's all about the level you're at, and how much the person or people you're trying to learn from are willing to share information in a way that you will understand. Case in point: DOS 5 had an EXCELLENT help system. Unix has MAN. I am JUST NOW starting to get useful information from MAN pages - they were TOTALLY incomprehensible to me at first. This is why sites like Linuxnewbie [] make NHF's (Newbieized Help Files) for people like me - MAN pages don't cut it if you don't already speak the language.

    Fawking Trolls! []
  • Unix wizards do not oppose simplification because it devalues their efforts; they oppose it because they have learned the value of complexity. One can simply do more given more options. I can customise my desktop to a much greater extent with fvwm2 than I can with Windows. I can fiddle with stuff to my heart's content. I cannot do that with a simplified tool because many of my favourite twiddly bits will have been removed.

    BTW, don't you love English? `Will have been removed' is such a nice long verb...

  • At the moment, I think that most of my colleagues only try to learn Unix from the surface: instead of learning how the system is built up and WHY it is built up that way, they just keep memorizing commands and their parameters.
    This book could be helpful to them, I think. I'll propose that it will be bought next time :)
  • by pixelbeat ( 31557 ) <> on Monday September 18, 2000 @05:30AM (#771817) Homepage
    I think Mike Gancarz' book:
    The unix philosophy []
    is better, from the "Think UNIX" title perspective
  • "huh?" yerself! Sit down and configure a Solaris box when all you know is Linux and see where you end up.

    I agree, this book sounds good to me. I'd like to see the underlying similarities in the *nixes.
  • "Dude", the point is, if the only *nix you've ever had the opportunity to use before is Linux, and your forced to mess with a Solaris box...uh, it's a little alien.

    Bully for you for all your *nix experience, may it stand you in good stead. Meanwhile, I don't have that background. I need to know how the different *nices are similiar. mind is made up, I don't know how they're similar.

    Yeah, I can copy files, list directories, edit files, etc. In that way, yes, they're similar, but until you mentioned "slice instead of partition..." I had no idea what "slice" was referring to.

    I think you've illustrated the point that other people have made. That gurus have gotten to the point of obtuseness in their knowledge.

    I'm as guilty of it as anyone though. I can't understand why the user can't figure out how to copy a file to a floppy disk, and I treat them as if they're an idiot, when the truth is, I'm an idiot for assuming everyone else in the world "should" know as much about "insert knowledge specialty here" as I do.
  • Just a note: Starcraft has run well under WINE for over a year, at least... Works For Me(TM).

    By the way, I see your bitchslap has ended... visible posting again, must be fun.

  • Hmmm, the only problems I had with it (once loaded) was that saving games would freeze up now and again... the fake registry is... well, the original registry is a hack, so emulate that, and... ugh... VMWare provides a cleaner solution, but (of course) <advocate=on> life would be better for everyone if games were ported to linux/BSD <advocate=off>. Then again, a reworked windowing system might not hurt...

  • See the last comment where I mentioned VMWare... that's my current solution, since I found it a lot easier than WINE (and although it does run all of Windows) it tends to be more stable than wine, and I can run a broader set of apps with less fussing... I'll have to check through some old backups to see if I have that registry...

  • by toofani ( 40106 ) on Monday September 18, 2000 @08:03AM (#771823)
    The Unix Programming Environment [], by Brian Kernighan and Rob Pike? It was first published in 1983 but is still very relevant.
  • Great shit, you might be on to something, Holmes! This 'Linux' OS is sold by Redhat and Linux-Mandrake, put on hardware from VA... and what OS does Slashdot talk about? You guessed it -- Linux!


    -grendel drago
  • Sit down and configure a Solaris box when all you know is AIX / HP-UX / IRIX / Ultrix / *BSD and see where you end up.

    (You can shuffle any of the others into the 'Solaris' position there with much the same effect.)

    That's exactly *why* a book that tries to teach the *concepts* behind Unix is a great idea, rather than learning the right magic for just the box you happen to be using now.

  • More books with this perspective are needed.

    This is why I always recommend the Frisch [] book from O'Reilly over the Nemeth Sysadmin book. It actually starts with files & processes and works its way up. I find that it gives a MUCH better grounding in WHY you do something a particular way as opposed to just explaining HOW you do it.

  • The Unix Philosophy is a good book for examining some of the underlying concepts in what makes a good program. It cuts to the heart of why so many people love Unix. It distills what makes shells and pipes and I/O redirection such powerful concepts and warns against many of the things that happen in creeping featurism.
  • I guess there's also a third school of thought, which is the "understand the complexity when and if you're ready to" school.

    You can see it at work in OS X and Eazel.

  • "Linux Companion: For Users and system Administrators". Mostly about converting MS-DOS concepts (hey, it was 1995ish) into UNIX-speak. Unfortunately, it was my first book and wasn't quite as clearly written as some of my later works. Also, Linux wasn't quite as popular in 1995 as it is now. Might even be in print still....I should check..
  • by zpengo ( 99887 ) on Monday September 18, 2000 @05:26AM (#771830) Homepage
    I think this would be a great book for many people out there who are somewhat new to the scene. *nix isn't just about memorizing commands; The real power is when you understand what goes on when you type the commands, so that you can put them together in strange and wonderous ways.

  • I really don't see your point. I've been using Linux for about 2 years, and I feel pretty competent by now. Certainly not a "guru" or "wizard" (I don't know C well and have done but one trivial change to the kernel source), but I pretty much understand the system from a user and administrator point of view. Unix, from my experience, is hardly ever "user hostile" - it was just written by and for people who're really knowledgeable about computers and can appreciate a utility like sed - difficult to learn, but astonishingly powerful when used properly. And the comparison with DOS 4.0 is ridiculous - any ease of use that had was simply a result of its lack of features.
  • I know where your coming from. I started with slackware in 94' and sometimes for the first couple of years i felt exactly like you. Now however I administer 3 flavors of Unix and 4 flavors of Linux for IBM. I can tell you the only difference between me now and then is hours of practice and reading (and a deep inner questioning of how things work). The reason "guru's" get tired of newbies is because we suffered and RTFM and asked how things worked. MSDOS has very little features so of course it didn't take you long to learn. If you don't have time to sit down and figure it out your not going to hurt my feelings. The less people who know how Unix works the more money sys admins will make ;).
    1. There's an errata for the book. It is, as far as I'm aware, entirely complete and up-to-date. It's over here [] (the address is listed in the book, yes). You can determine how many of these have any impact whatsoever on the content.
    How about some errata for the errata? :)

    p.31 - I assume that should be "Socrates", not "Soctrates"
    p.46 - "user", not "uger"
    p.123 - "last", not "lasgt"
    p.128 - "digits", not "difits"

    BTW, p.154 - æ is &aelig; :)

  • When you get right down to it - a core set of UNIX skills would be good for any linux enthusiast... They're portable between distributions - and heck you never know when you are going to be in front of a "linux-like" (that's a "Maddog" quote) operating system like AIX, HP/UX, Solaris or some BSD deriviative...
  • I'm assuming that you refer to the CLI since X is neither any less or more 'intuitive' than other GUI's (I'm sure there are those who would differ). The complexity you refer to allows efficiencies flexibility that just doesn't exist in the GUI realm. I run X on my Linux box, but I still find myself going to a term window to do many things that are actually easier from the command line or are nigh on to impossible in the GUI.
  • I think the performance issue is actually a perception issue. You don't have the option with the GUI OS's to do significant amounts of work from the CLI, so the system is as fast or as slow as it always is. If it's too slow, throw money into faster components or a new box. Of course, if all you're using is PING.....

    As far as being less intuitive, I don't think any GUI lives up to the 'intuitive' hype. I remember when the Apple Lisa came out and I watched all kinds of people move the mouse and click on icons and get frustrated when nothing happened. Not intuitive. We only think GUI's are intuitive because we've used them for such a long time.

  • There is an interesting article here [] about Unix/Linux as an element of literacy. Compare, say, windows' icons to the representative icons and symbols we see in real life and Unix's "complex" syntax that is more like a novel.

    This is part of the reason why it is important the OS doesn't get out of the hands of the people.

  • OK, my comments about tech writer personality types was off point. I was really criticizing the review more than the book. But as long as you as you bring up the subject...

    Danny's review left me with the impression that there were more than two code errors. I suppose that's a low enough rate to make me actually want to see the book, but I'm still bothered. Here are some general comments which may not apply to your book:

    Errata, revised printings, etc., can mitigate some errors, but there are absolutely things you must get right the first time. One early publisher had to recall an entire printing of the Bible because of one typo (a "shalt" instead of "shalt not"). Funny to us, but less humorous in an era when Religious Incorrectness was a capital offense. Or consider a similar error in a medical textbook...

    If your book is getting "messed up" by your editors, then your publisher has some basic problems. Why on earth do you need to do a lot of format conversions? If a publisher is serious about producing technical books in a computer era, they should be standardizing on one or two well-structured formats.

    You can argue that this kind of problem is not the author's fault. Perhaps, but I'm not particularly interested in assigning blame. I just want to know what authors and publishers produce work I can use.

    You mention "the Llama book". I assume this is something from O'Reilly -- I haven't memorized all their cute colophons. This is one publisher I have strongly mixed feelings about. On the one hand, they have some first-rate authors, are the only publishers of authoritative works on many topics, and have some carefully thought-out procedures [] for writing, editing, and production. On the other hand, they manage to produce a lot of badly edited books -- and even a fair number of paper doorstops. Not a gold standard, I'm afraid.

  • More commonly? I've met Perl programmers (yes, Perl programmers) who give me blank looks when I say "the Camel Book". Cute insider jargon and similar linguistic games are handy for making you sound ReeUlKeWl, but they're lousy for communicating technical concepts. That's the problem I have with a lot of O'Reilly books -- they put being cute ahead of being clear. And I'm afraid I seem some of that in what I've read [] of Lasser's book.
  • I'm on the lookout for a book like this. I'm involved in documenting a Linux product that's supposed to attract a lot of non-Linux programmers, and we desperately need some kind of Linux tutorial we can point users to -- perhaps even through in the box with the product. So of course I read reviews like this one very closely.

    It bothers me when the reviewer gives a book a positive rating, but then goes on to say, "but there are a lot of typos, and some of the code examples don't work." Imagine that you're a Unix/Linux newbie, and you copy a shell command from a book, and get some obscure syntax error. Unless you have the shell background to figure out what's wrong (and of course you don't, you're a newbiew) you're stuck. You'll probably put the book down and never pick it up again.

    Good technical communication is written by the anal-retentive. Sad, but true.

  • why not recommend the book?

    You can still run X on BSD, right? You can still run X on Mac OSX too...

  • huh? how can you be a linux enthusiast without a core set of unix skills? what linux skills are not portable to other unixalikes anyway? linux is unix, as are the BSDs.
  • Linux is a lot better as far as the included toolset

    you can run the same toolset under any unix.

  • so what? vfstab instead of fstab? slice instead of partition? Do you find that confusing? I don't.

    Dude, I configured my first unix back before there was a Solaris, or a SUNOS. But, I have configured a few Solaris boxes. Can't teach an old doggo new tricks? Try this: next time you need to configure a Solaris box, make life easy on yourself and go to [] first. pull it down and install the gnu tools via RPM. It's a breeze.

    I agree, this book sounds good to me. I'd like to see the underlying similarities in the *nixes.

    I thought you just said they're not similar? make up your mind :)

  • I completely and tottaly agree. Linux isn't user friendly, like it or not... it's guru friendly yes, but that's besides the point. I'm no guru, I can barely shell script, but I can recompile my kernel, add perhiphrels, install programs, etc. but if X refuses to load, I'm really screwed. Most newbs don't have the patience to "bend over and take it like a man" this is perfect for my unix illiterate friend
  • rm -rf /

    And if you don't need a help system before typing that, you sure will afterwards. Oops, I forgot Linux hard-deletes files with no recovery.

  • i learned UNIX/Linux by surfing the net,reading LDP, and crashing my PC! Newbies certainly doesnt need books to master UNIX althought getting one would help to a certain degree. There is no substitute for self-learning and determination.
  • I thought the goal was to get MORE people using Unix / Linux. Giving newbies harmful advice is only going to send them running back to momma Microsoft. Do you just take some kind of sick pleasure in screwing other people up? I supose if you were teaching someone DOS you'd tell them the online help system is called "fdisk." Jerk. Kasreyn
  • No Shit, I couldn't have stated it better myself. Linux/Unix/BSD are wonderful once you know what the hell your doing. The problem is for the most part Unix Admin's/GURU's are assholes and fell threated when you ask the questions on advanced topics. It's the GOD Complex..

If I have seen farther than others, it is because I was standing on the shoulders of giants. -- Isaac Newton