Introduction

I hope you get a lot of use out of this book. Since I first got started with Unix in 1986, I've spent a ton of cash buying reference books. I've always been a bibliophile, and computer books have the advantage of being tax deductible, so I've amassed quite a collection. It always annoys me when I get home and the glitzy, well-packaged, 400-page document-o-rama I just shelled out $50 for turns out to contain only 5 pages of actual information or, worse, to be full of information but so poorly organized that it's more trouble than it's worth to find what I need. I've got a shelf full of them, which I will sell cheap.

What I've tried to do here is incorporate the best features from my collection. I know what I like-a good index, thorough technical coverage, relevant examples, and concise explanations (in English). Also, in the process of writing this book I've become almost supernaturally attuned to the subject of computer reference books-you can whisper "Linux in a Nutshell" from 30 feet away across a crowded room and my ears will perk up like a retriever on point. The number one complaint I hear about reference books is "not enough examples." I'm not unsympathetic; thinking up, configuring, and testing all the examples for this book slowed the writing process down to a crawl. But, as my editor pointed out, I'm not doing this for my health. So you will find that for every command in this book there is an accompanying example.

To some extent, Linux commands tend to come in clusters. For example, there are a dozen or so that handle filesystems, another half dozen for fiddling with disks, a whole slew that do things with files, and so forth. Sometimes the command clusters follow a naming convention, as in the case of the "remote" commands (rlogin, rsh, etc.); other times they do not. It occurred to me that it wouldn't be entirely wrong to group the Linux commands into clusters (one for users, another for disks, etc.) and then treat the clusters as data structures. Technically, a data structure consists of two things:

• a specification for how data will be stored
• a specification of methods by which the data will be accessed

That's not a perfect description of how the chapters are arranged, but it isn't bad either. At the beginning of each chapter there is a high-level discussion of what purpose each "data structure" serves, how that service is accomplished, and the jargon that has sprung up around it. This provides background for the detailed description of commands that follows. Hopefully, this will provide enough information for newcomers to get started and perhaps be of some value for experienced users as well.

Of course, as you can tell from a quick glance through the contents, the main thrust of this book is information on actual user commands. I have collected what I believe to be a fairly thorough subset of the most useful Linux commands, together with their options and some suggestions for use. Information on configuration and use of the various subsystems (e.g., NIS, Samba, Networking) is also included, either explicitly or as part of the examples.

How to Use This Book

When You Know Exactly What You Need

For the advanced users who know exactly what command they are after and are looking only for examples or command line options, the book has two command indexes:

• all commands are indexed in the back of the book, as are term definitions, procedures, and the rest of the content.
• there is a second index in the front for executable programs only.

When You Know What You Need But Not What It's Called

Did you ever find yourself digging around looking for a command that you know must exist, only you don't have any idea what it might be called? Back when I was in school I clearly remember fumbling around for an hour trying to figure out what command I'd use to lower the priority of a running process. There was nothing in the man pages under "priority" or "process," but I knew it had to be out there somewhere.

This book is arranged by concept. If you want to find out how to do something with filesystems, flip to the chapter on filesystems. In each chapter, there's a brief discussion of relevant terms and concepts, followed by a one-line summary of all the relevant commands, a list of related files, and finally a complete listing of the commands with options and examples.

When You're Just Getting Started

This book explains all of the basic concepts you need to understand to use your Linux system. If you're not familiar with particular terms, they are defined in the text and indexed in the back. There's also a glossary. For every command, there is at least one example. For the more popular or confusing commands, there are frequently two or more. Where I thought it would be helpful, I included diagrams and sample output.

Conventions of This Book

Introductions

There's a certain amount of overhead involved in learning the Linux system. Some of the concepts can be counterintuitive at first glance, particularly if you're still in the process of switching over from one of the lesser operating systems. Each chapter in this book starts off with a few of pages of notes about the concepts, terms, and theory underlying the commands. Hopefully, this will help you get a feel for how the commands make up subsystems and how the subsystems make up Linux.

Related Files

Most Unix commands take configuration or startup information from one or more files. The entries in this section are a listing of the files associated with the commands in each chapter.

Commands

Each chapter contains a detailed listing of commands, together with options and examples.

A Final Word

Any single book that purports to cover the entire Linux operating system is probably lying. There's so much going on that what you can fit between two covers is, of necessity, a reflection of the experiences and prejudices of its author. To the extent that I neglected I really do apologize. If it's any consolation, it wasn't from lack of effort. If you have comments, corrections, or suggestions for improvement, feel free to contact me at:

As a postscript, some of you may be wondering about the significance of the Minotaur on the cover of this book. Tradition has it that Daedalus, a mythological inventor and the spiritual ancestor of hackers everywhere, built a large and complex maze in Crete (the Labyrinth, capital L) at the behest of King Minos. The Minotaur was a bastard child of the Queen Pasiphae (Minos' wife) and some unusually handsome livestock. He had a man's body and the head of a bull, which (understandably) made him a bit shy and grumpy. Perhaps as a consequence, he was also very territorial—he never left the Labyrinth, and ran it with an iron fist. Most significantly, the Mintaur had little patience with incompetence. He was famous throughout the kingdom for biting the heads off any ignorant schmucks who became lost in his world. When I was asked to suggest a mythological beastie for the cover of a system administration text, there was really only one choice.