Slashdot Mirror
Unix in a Nutshell
Greetings, all. This week I'll be "reviewing" one of the books that made the O'Reilly name, UNIX in a Nutshell, although I admit to feeling a little silly passing judgement on a book that has already been judged quite well by the community at large. The first edition of this book was published in December 1986, and has been a mainstay ever since. This particular version is dated June 1998, and professes to include typographical fixes and a new index. For reference, in December 1986 I was working on an IBM PCjr expanded to 640k of RAM and dual 360k floppy drives. My favorite games were Karateka, Flight Simulator II and F-15 Strike Eagle (the first one). How far we've come....
What's the book about?
Simply put, this book is a dictionary of UNIX. It lists every command
available with a standard System V, Release 4 or Solaris 2.0 UNIX. This
included everything from grep to ed to cc to troff. If you know a command
exists, it's listed here along with all its options. That, however, is but a
small part of the book. In addition, there are various specific sections
covering shells (including sh, ksh and csh), EMACS, vi, ex, awk, sed,
nroff/troff, mm/ms/me, various nroff/troff preprocessors, RCS/SCCS, make,
sdb/dbx, plus a small beginner's list of important commands. In other words,
this is the jack of all trades reference for UNIX (and by extension, the
master of none, although I'll cover that later). There is also a transition
guide (or at least a small blub) for those used to BSD instead of SysV (of
which Linux is a decendent of the later). Many BSD commands included in /usr/ucb on Solaris are listed in the guide as well. In short,
if it's standard UNIX (and then some), it's here.
If you want a kitchen-sink reference to UNIX, this is it. Any command that you have a question about is in here. Anytime you have a question about which vi command is needed, it's in here. Shell scripting is covered. Regular expressions are covered, for when you forget when to use "?" and when to use "*" (or "^" or "$"). Want a quick overview to RCS for your web files? It's right here. This is the short, short version of all your man pages that you can put under your pillow at night.
What's Bad?If you don't know much or anything about UNIX, don't buy this book. Or at least buy an introductory one along with it. Trying to learn UNIX from this book is like trying to learn English by reading the dictionary. Not only is there not much context, you can't do a reverse lookup. If you can't guess at the command you want, you won't be able to find it. That's not necessarily a flaw, this book just wasn't designed to do that. You don't buy the OED for a Spanish speaker, and you don't buy UNIX in a Nutshell for a newbie. In addition, don't buy this book just for its EMACS or vi or RCS section. Those sections are nice, but they are more command lists than guides. O'Reilly has an excellent selection of books dedicated to helping you with one of the above programs. They're great, and I recommend them.
What's In It For Us?Long-time UNIX fans will love this book, and probably already own a copy. Same with sysadmins. If you've been around enough to know what you're doing, but still have to look up commands, this is also a great book for you. I know I can never remember half the EMACS or vi commands when I need them. The community has voted, and this reference is it. If you need it, buy it.
Buy the book at Amazon.
Posted by d106ene5:
This book provides information that can almost entirely be derived from man pages. It adds very little to system documentation already in place (that any unix user should be comfortable using).
Unfortunately, technically speaking, only catpages not manpages are required. Perhaps that's what you meant. But even catpages are better than nothing.
This hardly constitutes a fine selling point in your favor. Sometimes the FSF pertains more to the problem set than they do the solution set; this is certainly one of those places. Not only do they ignore the POSIX requirements, they appear to disavow the need for a unified, indexable, searchable, printable, formalized set of technical documentation. This is hardly what most of us would call `progress'.It's bad enough when you summon up a manpage only to be infuriatingly chidden by the FSF that `This documentation is no longer being maintained and may be inaccurate or incomplete.' Worse still is the situation with programs like diff or gnomecal, which are completely bereft of any manpage whatsoever. The FSF should be ashamed of themselves! This is one of the root causes of the notorious Daemon Linux project.
This lackadaisical attitude toward complete, on-line documentation is hardly confined to the FSF, although I hold them ultimately responsible for one area: Linux distributors. The Linux rebundlers inherit the problem from the FSF, and do nothing about it. Take SuSE for example. In virtually all other aspects a robust and coherent Linux distribution, SuSE confesses in their printed book that accompanies their CD that not all commands and functions have documentation. What a punt! They're just being irresponsible.
I suppose that one could in desperation invent some sort of rarefied alibi for the FSF's negligence here. They are, after all, more dedicated to principle than they are to mundane matters of quotidian utility. But for those who repackage and sell Linux distributions, no excuse can exist. These businesses are selling what they purport to be an integrated system, yet then have the audacity to confess that it is not. If the FSF won't fix this, then the resellers must. But the FSF really is the right place to fix it, because that way the fix helps everyone, rather than just one reseller trying to create a market advantage for themselves.
But this already depressing situation gets worse, far worse, before it gets better. You see, as programmers try to create something flashy enough to attract non-programmers, something critical has been lost. I'm thinking of those programs whose GUIs are the Way, the Truth, and the Light, whereby no man cometh unto the documentation for a given program save through its lauded GUI. If the information is not found under an About button or a Help button, it simply isn't available. Even if it were to be found there, how would you know it? Once you figure out each program's new set of hieroglyphics, these miserable shinyhappy icons and their cascading shinyhappy menus just aren't greppable. How do you in a non-manual fashion search through these myriad menus? How do you print them out? How do you create an index?
This situation in completely unacceptable.
Having recently tried out the whole Eterm, Enlightenment, and Gnome set-up, as duly impressed as I was with Eterm's manpage, I was severely underwhelmed by the attention toward detailed -- strike that, make it any -- documentation manifest in the other two. Miguel has assured me that what I had looked at was a mistake, that the released snuck out without the libraries' docs included. But I want more than only the programming libraries having manpages. If it's a command or a file format, it needs to be documented! Otherwise we're back to the mushroom school of systems management (keep us in the dark and feed us shit). Every little gnomic panel application and associated happycon needs a manpage, one that apropos and whatis can access, as well. Don't make me click with a mouse to find help and directions. I didn't spend thirty years mastering the keyboard and learning to read and write lengthy treatises merely to be reduced to a one-bit input device and a two-line output device.
Having to randomly hunt through manpages, HOWTOs, info pages, various programs' home pages out on the Web, per-program help pages, and stringsing the infernal binaries is shear madness As Henry Spencer observed, `Those who do not understand Unix are condemned to reinvent it, poorly.' Unified Unix manpages solved the insane situation in which you had shelves upon shelves of printed documentation that came with an IBM mainframe; these docs weren't online, so were unnavigable. Apparently we are doomed to repeat that unhappy history.
While it's true that I write all my books in troff, along with the traditional helpmates of eqn, pic, and tbl, please don't assume by this that I am particularly enamoured of that system. I'm certainly not. What I do expect in proper online documentation is the properties that manpages provide:
- All documentation must be contained and accessible from within the same on-line system.
- Available for independent on-line viewing, apart from the application.
- Format easy to read and write by humans, parse and generate by programs.
- Conveniently structured.
- Printable as a high-quality book using a typesetter.
- Searchable and indexable using standard tools.
The language used to encode this information is far less important than is having these basic features. Without a coherent, comprehensive, and unified documentation system, we might as well all be running some expert-hostile and user-obsequious toybox suitable for the point-and-drool atechnical public all too typical in these post-literate Dark Ages, where WYSIWYG means that what you see is all you get.--tom