The Unix-Haters handbook Page 80 (80 of 360)

40 Welcome, New User!

The Unix Attitude 41

Previous Page Next Page

The Unix-Haters handbook resources

Download PDF The UNIX- HATERS Handbook (358)

Attachments

Extracted Text (may have errors)

40 Welcome, New User!

The Unix Attitude 41

Help

38 Welcome, New User! Most of you, of course, don’t use Unix, so knowing how to kill a job may not be useful. However, some of you, like me, may have occasion to run TeX jobs on it periodically, in which case knowing how to kill jobs is vital. In any case, the design principles underlying the “kill” command are applied rigorously throughout Unix, so this message may be more generally useful. Unix lets you suspend a job with ^Z, or quit and kill with ^C. LaTeX traps ^C, however. Consequently, I used to pile up a few dozen LaTeX jobs. This didn’t really bother me, but I thought it would be neighborly to figure out how to get rid of them. Most operating systems have a “kill” command. So does Unix. In most operating systems, the kill command kills a process. The Unix implementation is much more general: the “kill” command sends a process a message. This illustrates the first Unix design principle: • Give the user power by making operations fully general. The kill command is very powerful it lets you send all sorts of mes- sages to processes. For example, one message you can send to a pro- cess tells it to kill itself. This message is -9. -9 is, of course, the largest single-digit message, which illustrates another important Unix design principle: • Choose simple names that reflect function. In all other operating systems I know of, the kill command without an argument kills the current job. However, the Unix kill command always requires a job argument. This wise design choice illustrates another wise design principle: • Prevent the user from accidentally screwing himself by requiring long commands or confirmation for dangerous operations. The applications of this principle in Unix are legion and well docu- mented, so I need not go into them here, other than perhaps to allude in passing to the Unix implementations of logging out and of file deletion. In all other operating systems I know of, the job argument to the kill command is the name of the job. This is an inadequate interface, because you may have several LaTeX jobs (for instance) all of which

The Unix Attitude 39 have the same name, namely “latex,” because they are all LaTeX jobs. Thus, “kill -9 latex” would be ambiguous. Like most operating systems, Unix has a command to list your jobs, mnemonically named “jobs.” The output of jobs looks something like this: zvona@rice-chex jobs [1] - Stopped latex [2] - Stopped latex [3] + Stopped latex This readily lets you associate particular LaTeX jobs with job num- bers, displayed in the square brackets. If you have had your thinking influenced by less well-thought-out operating systems, you may be thinking at this point that “kill -9 1” would kill job 1 in your listing. You’ll find, however, that it actually gives you a friendly error message: zvona@rice-chex kill -9 1 1: not owner The right argument to kill is a process id. Process ids are numbers like 18517. You can find the process id of your job using the “ps” command, which lists jobs and their process ids. Having found the right process id, you just: zvona@rice-chex kill -9 18517 zvona@rice-chex [1] Killed latex Notice that Unix gives you the prompt before telling you that your job has been killed. (User input will appear after the line beginning with “[1]”.) This illustrates another Unix design principle: • Tell the user no more than he needs to know, and no earlier than he needs to know it. Do not burden his cognitive capacities with excess information. I hope this little exercise has been instructive for you. I certainly came away from my learning experience deeply impressed with the Unix design philosophy. The elegance, power, and simplicity of the Unix kill command should serve as a lesson to us all.

Previous Page Next Page

The Unix-Haters handbook resources

Download PDF The UNIX- HATERS Handbook (358)

42

3 Documentation? What Documentation? “One of the advantages of using UNIX to teach an operating systems course is the sources and documentation will easily fit into a stu- dent’s briefcase.” —John Lions, University of New South Wales, talking about Version 6, circa 1976 For years, there were three simple sources for detailed Unix knowledge: 1. Read the source code. 2. Write your own version. 3. Call up the program’s author on the phone (or inquire over the network via e-mail). Unix was like Homer, handed down as oral wisdom. There simply were no serious Unix users who were not also kernel hackers—or at least had ker- nel hackers in easy reach. What documentation was actually written—the infamous Unix “man pages”—was really nothing more than a collection of reminders for people who already knew what they were doing. The Unix documentation was so concise that you could read it all in an afternoon.

Previous Page Next Page

The Unix-Haters handbook resources

Download PDF The UNIX- HATERS Handbook (358)

Page 1The UNIX- HATERS Handbook click to expand contents

Page 3The UNIX- HATERS Handbook click to expand contents

Page 17Foreword click to expand contents

Page 21Preface click to expand contents

Page 37Anti-Foreword click to expand contents

Page 43Unix click to expand contents

Page 57Welcome, New User! click to expand contents

Page 83Documentation? click to expand contents

Page 101Mail click to expand contents

Page 131Snoozenet click to expand contents

Page 149Terminal Insanity click to expand contents

Page 161The X-Windows Disaster click to expand contents

Page 185csh, pipes, and find click to expand contents

Page 211Programming click to expand contents

Page 239C++ click to expand contents

Page 257System Administration click to expand contents

Page 279Security click to expand contents

Page 295The File System click to expand contents

Page 315NFS click to expand contents

Page 335Epilogue click to expand contents

Page 337Creators Admit C, Unix Were Hoax click to expand contents

Page 341The Rise of Worse Is Better click to expand contents

Page 347Bibliography click to expand contents

The Unix-Haters handbook resources

All section downloads (PDF) click to expand contents

Attachments

Extracted Text (may have errors)

Help

loading

The Unix-Haters handbook resources

The Unix-Haters handbook resources