Preface

Because of its robust and stable nature, the Linux-based system is the choice of millions today. But what some may not know is that the free software movement, of which Linux is a part, is very much a counter-cultural phenomenon: the design by which it is produced and published is contrary to the notions of proprietary, intellectual "property" that have dominated mainstream culture so long. While some programmers turn their research into corporate-backed software that you cannot openly change, share, or examine (but only purchase and run on your system), Linux and other free software is the product of many individuals who courageously published and shared their research and work openly, for everyone to benefit from.

I wrote this book because I want everyone to know how to use this software, because I think everyone deserves the freedom that comes with it. I don't willingly use proprietary software--not because it is always inferior to free software, but because its use precludes freedoms that I find I cannot exist without ... freedoms that should be everyone's right by default in a free, open society. (See Introduction.)

I know that Linux isn't difficult to use, especially when compared with other software and operating systems, but what was needed was a guide to show people how to use it to get things done: "Oh, you want to do that? Here, type this."

That explains the premise of the book--it's a hands-on guide to getting things done on a Linux system, designed for the everyday user who is not necessarily a computer programmer.

The traditional approach to the subject is to either provide laundry lists of all available commands and applications, or focus on their use in a programming or otherwise technical environment. This book takes a different approach, showing how everyday users--be they artists, designers, businessmen, scholars, or scientists--can use these tools and applications to get things done. When I speak of "things," I mean (hopefully) the kind of things that you--the sort of person possibly and partially described above--might want to do with a modern computer system: view text and images, play and record sounds, perform mathematic operations, print to your printer, format text, access the Internet, check your grammar, and so forth.

Like a culinary cookbook, this book presents "recipes" for preparing or accomplishing a particular, specific thing. I've selected what I consider to be the easiest and most effective methods for accomplishing particular tasks, and have arranged these recipes in general sections according to subject matter--the first part of the book is all about getting started, and contains the most essential information you need to know about using Linux; the remaining chapters deal with general categories of usage: Files, Text, Images, Sound, Productivity, and Networking.

1.0 Format of Recipes		Organization of recipes.
1.1 Assumptions, Scope, and Exclusions		Assumptions, scope and exclusions.
1.2 Typographical Conventions		Typographical conventions.
1.3 Versions, Latest Edition, and Errata		Versions, latest edition and errata.
1.4 Acknowledgments		The people who helped with this book.

1.0 Format of Recipes

Each recipe is numbered with at least two figures. These figures are constructed as follows: the first number always corresponds to the chapter number, and the second to the section of the recipe. For example, Chapter 3 is The Shell, and Recipe No. 3.5 is the fifth recipe on shells, Recording a Shell Session.

Sometimes recipes are divided into subsections, with a third number specifying the specific recipe--for example, Recipe No. 3.4 is on the subject of command history in the shell, and is divided further into subsections; Recipe No. 3.4.2 is the second recipe on command history, Specifying a Command from Your History.

Each recipe describes a method for completing a specific task on the system; these tasks require at least one software program. The software programs or files a recipe calls for are its ingredients.

The recipes are structured as follows:

1. Recipe number and title of the recipe.

2. Special ingredients, if any. The Debian package(s) and/or or URLs where the program(s) can be obtained are listed, if they are available.

   Debian classifies packages in varying level of importance, from `required' packages that all systems must have in order to run, to `optional' and `extra' packages that you only install if you want them. If a described software package is in the first two given categories---`required' and `important'---then I assume you have it installed, and the package name isn't listed here.

   In the rare case that a software package I describe is not yet available as a Debian package, I just give the URL where to obtain the source packages for that software; have your system administrator install it.

3. Special preparation methods or description, if any. When a configurable program is described, the standard setup as provided by the Debian distribution is assumed, unless otherwise specified here.

4. Description of the recipe and "cooking" method proper.

5. Remarks concerning the results and use.

6. Bulleted example of the method in a specific context.

7. Extra commands or actions you might want to do next.

8. Variations on the recipe, with additional examples.

9. Special notes or references to further information.

Not all of these items may be present in a given recipe.

1.1 Assumptions, Scope, and Exclusions

There a few assumptions that this book makes about you, the reader, and about your Linux system.

The Cookbook assumes that you have at least minimal understanding of your computer hardware--you don't have to know how to take it apart or anything like that, but you ought to know how to operate the mouse, where the power button is on your computer and monitor, how to load paper in your printer, and so forth. If you need help with any of these tasks or concepts, ask your dealer or the party who set up your computer.

This book also assumes that you have Linux installed and properly set up, and that you have your own user account set up on your system. If you need help with this, please see If You Need More Help.

While this book can and should be used by the newcomer to Linux, I like to think that I've presented broad enough coverage of the Linux-based system, and have included enough interesting or obscure material, so that wizards, hackers, and members of the Linux Cabal may find some of it useful--and that said users will not feel ashamed to have a copy of this book on their desk or as part of their library.

Finally, a note about what isn't covered in the Cookbook.

This book describes only free software (sometimes called "open source" software) that runs on Linux systems.(1) Proprietary software is omitted, as are most software packages that are currently in a "beta" or some other unstable release not yet intended for general use.

Some programs take a number of options that modify the way they work. Sometimes, various options that a tool takes are listed in a table. These lists are not exhaustive; rather, they contain the most popular or useful options, or those options that are relevant to the discussion at hand. Consult the online manual page of a particular tool for the complete listing (see section Reading a Page from the System Manual).

This is a user manual; no computer programming activities, such as program compilation, are discussed. Topics related to system administration are also omitted--so you won't find anything in this text on matters such as managing accounts, system maintenance, setting up hardware, and configuring networks.

As with any rule, you can find an exception to this--if you look hard enough for it. If you are running Linux on your home computer as a single-user system, you are also the administrator of this system, and are the responsible party for ensuring that any administrative tasks be completed; Administrative Issues exists as a reference for those users who will be administrating their own systems.

1.2 Typographical Conventions

All recipes have at least one example that demonstrates it.

• The text that describes what the example does appears just before the example itself, and is offset from the text with a bullet, like this.

• A given recipe may have several variations; each is offset with its own bullet.

• The names of documents or users that are used in some recipes may not always reference actual documents or users on your system, but demonstrate the general principles involved. So when I show how to print a file called `resume', you might not necessarily have a file with that name on your system, but you should understand the idea which the recipe demonstrates.

Sometimes, a terminal screen is shown to illustrate an interactive session:

$ Text that you actually type is displayed in a slanted font, like
this. If it is a command to be typed at a shell prompt, the command is
preceded with a `$' character.

Text that denotes program output is displayed in a monospaced Courier
font like this.

$

In examples where a shell prompt is displayed, the default current working directory is omitted in the prompt and just a `$' is used; when a command outputs text and then exits, the last line of an example contains a `$' character to denote the return to a shell prompt. Don't worry if this sounds strange to you now; all of this "shell" business is explained in The Shell.

When a command exits and returns to the shell prompt without outputting text, the final shell prompt character is omitted, and a cartouche border is not drawn around the example; this was purely an aesthetic decision.

The names of files or directories appear in the text as `file'; commands appear as command, and strings of text are typeset like `some text'. GNU INFO BUG: Note that the differences in fonts and appearance are mostly lost in the Info version.

Text you type is written like this, just as in the examples, and when a specific key on the keyboard is mentioned, its conventional name is displayed in a box. For example, RET denotes the `Return' key on the keyboard.(2)

In examples where keys are meant to be pressed and held down together, the keys are separated by hyphens; the hyphens are not meant to be literally pressed. For example, pressing the CTRL, ALT, and DEL keys and holding them down at the same time is a combination that has meaning in some operating systems (including Linux, where this keystroke means to shut down the system and reboot the computer); it is represented like this:

CTRL-ALT-DEL

The CTRL (`Control') key is always used in combination with another key; these combinations are denoted by C-x, where x is the second key. These combinations are read as `control-x', where x is the name of the second key. To type one of these combinations, press and hold CTRL, press the second key, and then release both keys.

• For example, to type C-d (pronounced `control d'), press and hold CTRL, type the D key, and then release both keys.

In some applications (notably, the Emacs editor; see section Emacs), the META key is used with another key, in the same way as SHIFT; these combinations are denoted by M-x, where x is the second key. Most keyboards today don't have a META key, even though the term is still in use; instead, press and release ESC, and then type the second key.

• To type M-c, press and release ESC, and then press and release the C key.

You can sometimes also use the ALT key for the META key. This often does not work in the X Window System, but in the console you can press and hold ALT and then type the second key just as you would with a CTRL key sequence.

• So to type M-c with the ALT key, press and hold ALT, press the C key, and then release both keys.

Both CTRL and META sequences are not case-sensitive; that is, pressing X in the last example is the same as pressing x (although x is certainly easier to type). By convention, the C- or M- prefix is always given as an uppercase letter, and the key which follows is always given as a lowercase letter.

Menu items in an application are written like Menu Item; the names of command functions are written as Function.

For aesthetic purposes, a physical space appears in the text between commands and the final RET that ends a command line, and should not be literally typed (although nothing bad will happen should you actually type this space). Where explicitly pressing the space bar is called for, that key is represented in examples by SPC.

1.3 Versions, Latest Edition, and Errata

@sf{WWW}: http://dsl.org/cookbook/

Every effort has been made to include only the best free software recipes for accomplishing tasks in the easiest and most efficient manner, and they are believed to be correct. Suggestions, comments, and bug reports are always welcome; you can contact the author via email at [email protected].

1.4 Acknowledgments

This is not a book that was borne easily. Conception, took but an idle moment--but once the idea had been implanted, I found resistance and setbacks at every turn. It was only through the help of the following individuals that this book with my name on its cover was finally brought forth, and has now found its way to you.

Everyone involved with this book at No Starch Press deserves a hearty round of thanks. Bill Pollock has published this book precisely according to its author's vision, and had the discernment and foresight to allow that a copylefted edition (with corresponding source data) be made available in conjunction with the hardcopy book. Project manager Karol Jurado worked ceaselessly to keep the production flowing, while dealing with my input files, and giving opinion and advice on all manners of obtuse esoterica whenever the sudden need to know came over me. Both Elisabeth Beller and Andy Carroll contributed improvements to the text.

Steve Turner and the National Writers Union played a major role in helping to ensure that this book could be completed, copylefted, and in the hands of Linux users like yourself. Carol Cricow gave invaluable legal assistance, and various advice and assistance came from the NWU's JoAnn Kawell, Philip Mattera, Judy Heim, and Bonnie Britt.

Wendy Seltzer, Fellow, The Berkman Center for Internet & Society at Harvard Law School assisted with the conception of the Design Science License (DSL), which is used in this book. She gave an initial review of the license draft and provided her expertise and advice throughout the entire process.

Thanks to David Sims, Chris Coleman, and Terrie Schweitzer, who've all been great folks to work with at the O'Reilly Network, where my "Living Linux" column runs.

I am indebted to Buwei Yang Chao, whose How To Cook and Eat In Chinese (John Day Company, 1945) served as much of the inspiration behind the tone and structure of this book. I feel the same regard for two other authors who have come before me, and whose work has had a direct influence in the writing of this book--Dr. Lee Su Jan (The Fine Art of Chinese Cooking, Gramercy Publishing 1962) and Andrew Walker (The UNIX Environment, Wiley 1984).

Thanks also go out to Kenneth W. Melvin, and to the members of the "Byline" forum on the WELL; both were sources of advice and feedback early in the project. The art-hackers of the linart mailing list entertained initial discussion of the idea of this book as it first occurred, and the "elders" Ann and Walt gave various support for which I am grateful.

Finally, I must thank Jack Angelotta, Jon Konrath, Steven Snedker, and mrs (Marie Stutz), who all listened to the unbelievable as it happened, and stood by--even in moments of terror.