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.