The Unix Attitude 37 The Unix Attitude We’ve painted a rather bleak picture: cryptic command names, inconsistent and unpredictable behavior, no protection from dangerous commands, barely acceptable online documentation, and a lax approach to error check- ing and robustness. Those visiting the House of Unix are not in for a treat. They are visitors to a U.N. relief mission in the third world, not to Disney- land. How did Unix get this way? Part of the answer is historical, as we’ve indicated. But there’s another part to the answer: the culture of those con- structing and extending Unix over the years. This culture is called the “Unix Philosophy.” The Unix Philosophy isn’t written advice that comes from Bell Labs or the Unix Systems Laboratory. It’s a free-floating ethic. Various authors list different attributes of it. Life with Unix, by Don Libes and Sandy Ressler (Prentice Hall, 1989) does a particularly good job summing it up: • Small is beautiful. • 10 percent of the work solves 90 percent of the problems. • When faced with a choice, do whatever is simpler. According to the empirical evidence of Unix programs and utilities, a more accurate summary of the Unix Philosophy is: • A small program is more desirable than a program that is functional or correct. • A shoddy job is perfectly acceptable. • When faced with a choice, cop out. Unix doesn’t have a philosophy: it has an attitude. An attitude that says a simple, half-done job is more virtuous than a complex, well-executed one. An attitude that asserts the programmer’s time is more important than the user’s time, even if there are thousands of users for every programmer. It’s an attitude that praises the lowest common denominator. Date: Sun, 24 Dec 89 19:01:36 EST From: David Chapman zvona@ai..mit.edu To: UNIX-HATERS Subject: killing jobs the Unix design paradigm. I recently learned how to kill a job on Unix. In the process I learned a lot about the wisdom and power of Unix, and I thought I’d share it with you.

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