Preface


preface

This book is a labor of love. It’s based on a series of weekly columns I began writing for Linux.com in the fall of 2003. Before I get into the meat of the book, I would like to explain what I mean by saying a labor of love. The answer is all wrapped up in what the book is about and who it is for.

Why the CLI?

The CLI, aka the Command Line Interface, is your window into the soul of Linux. Grok the shell, grasshopper, and the mysteries of the kernel give themselves up like cat-burglars caught in the glare of a SWAT team’s spotlights. There is more to learn here than the syntax and function of commands. At the CLI, you learn how Linux thinks, and why it behaves as it does.

It’s also a boogeyman. It’s been held up as being difficult to learn so often that the mere mention of it frightens the uninitiated. I love the CLI, not just because it has taught me so much about Linux, but because it helps me do what I need to do in the quickest, most efficient way.

I’m not hardcore about the CLI. Not like David Graham, a colleague of mine at OSTG. Most of the time I spend in front of my computer, I’m in a GUI desktop environment. I simply try to use the best tool for the task at hand.

That means that at least a dozen times a day I visit the CLI. When I do, it’s because the CLI provides the easiest, quickest way to do whatever it is I need to do. When I’m finished, I’m back in the GUI again. Don’t fret that I’m going to try and wean you completely off the GUI, because I’m not. I’m just going to try to lure you outside of it now and then.

A Noobie Error

One mistake that’s often made is to confuse the CLI with the DOS prompt. Don’t do that. It’s a grave injustice to the shell. Why? Allow me to quote Linus Torvalds, the father of Linux, from his book “Just for fun.

Describing the very earliest stages of Linux development, he said “The shell was operational, which meant that I had actually built the foundation of a working operating system.”

A little later in the book, Torvalds mentions the shell again:

What is special about Unix is the set of fundamental ideals that it strives for. It is a clean and beautiful operating system. It avoids special cases. Unix has the notion of processes – a process is anything that does anything. Here’s a typical example. In Unix the shell command, which is what you type to gain entry into the operating system, is not built into the operating system, as with DOS. It’s just a task. Like any other task. It just happens that this task reads from your keyboard and writes back to your monitor. Everything that does something in Unix is a process.

See? If you’re coming to Linux from Windows, you’ve already learned something important: the shell is the same as a web browser to the kernel. And because you have, you’ve already got a head start on what can be learned at the CLI: the Zen nature of the operating system itself.

Why for Noobies?

I have a particular interest in and fondness for writing for newcomers. I’ve had it for as long as I’ve been involved with computers. In my programming days, that often meant trying to write clear, concise, understandable code, then supplementing it with relevent, meaningful comments.

Why? I guess it’s partly because I’ve been frustrated when the path to learning was more difficult than it had to be.

I can still remember reading an introductory text on IBM/360 Assembler programming, in 1976, in which the author casually noted that he was sure that whatever it was he was trying to explain at the moment was “brutally incomprehensible” to the readers.

I also remember how difficult it was to configure the Opus BBS and BinkleyTerm mail-tosser I set up in 1990, because of the lack of intelligent documentation. Things shouldn’t be that hard to learn.

On the other hand, I also recall the angels of introductory learning that I’ve run across: the User Manual that accompanied my Epson MX-80 printer; the long, instructive posts of Roedy Green on Bix, and W. Richard Stevens’ works on TCP/IP.

All of these have increased my enjoyment, productivity, and general knowledge of computing. That’s what I hope this primer on the CLI will do for noobies.

Noobies? That sounds like you’re dissing us!

It sure does, that’s why I use it. One of the knocks against Linux has always been that in order to learn anything about it, you have to suffer all sorts of disrepectful commentary from the 7th graders who joined the community before you did.

I use the term noobie and grasshopper (as in a young boy studying at a Buddhist monestary) for comedic relief throughout the text.

But don’t worry, it’s them I am making fun of, not you. We’re all noobies at something, at every stage of our lives. It doesn’t mean we’re not intelligent, educated, or cool. It means something is new to us.

This book is aimed directly at those just coming to Linux from other environments. There are more of us every day, it seems. In it, I’ll try to cover things that will make you more comfortable running Linux on your desktop, not on your server, so that you can free yourself — and your desktop — from the tyranny of the monopoly.

What we’ll cover

The CLI is more than just shell commands. There are thousands of other things that can be done here, from ordering pizza to cracking weak passwords. The book is divided into four sections: In the Shell, Applications and Tools, Networking and Security, and Fun and Games.

The book is not designed to be read from beginning to end, like a novel. But I do recommend that you start by reading the first section and the first two chapters of the second section before diving into the others. They will provide you a good foundation for your exploration of the CLI.

After that, let your interest and your needs lead you from one chapter to the next. That’s what the index and the table of contents are designed to help you do.

All the chapters in all the sections are small, bite-sized morsels, focused simply on the topic at hand. Beyond the basics covered in the first five chapters, you won’t need additional reading to make any of the other chapters easy to read and understand.

None of the chapters goes beyond the basics, and almost every one ends by encouraging you to learn more about the topic it covered.

Styles and conventions

Every time the book references a command to be entered at the CLI, or shows the output from a command to the console, the example will be framed as shown below:

linux~>command

That breaks down into three parts: the command prompt (“linux~>”), the command itself, and then one or more arguments needed by the command in order for it to do whatever it is you want it to do. Arguments can be options, file names, or whatever is needed. See? It’s not rocket science, it’s 1-2-3. It’s really that simple.

At times, you may be asked to enter data into a text file. In those cases, the data to be entered will be framed in a window similar to what we used for the CLI, but without the borders. Like this one:

line of data

line of data

line of data

When I want to stress a point, but not shout it, I’m apt to enclose the comment in a frame designed to catch your eye, like the one below.

Hard to drag your eyes away, isn’t it?

And finally, for a few, really important things, which need to be heavily stressed, I’ll frame them like this:

No noobies were killed in the production of this text. All models are over 18. Void in Oklahoma.

A few words of thanks

I’ll conclude the preface by saying thanks to all my family for their encouragement and support: especially to my older, wiser brother Allen and my younger, better looking sister Peggy; to the Malucci family for their encouragement; to Nicholas Petreley for giving me the opportunity to start writing about Linux; to Robin Miller for letting me do the columns this book is based on; to the readers of those columns for correcting my errors; and finally, in order to show solidarity with The Case for the Serial Comma, I would like to thank my godparents, Dorothy Parker and Baud.

This book is dedicated to my spiritual guide and fitness trainer, Susan Montaner.