Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Why was it decided to call the kill command "kill"?

I mean, yes, this utility is often used to terminate processes, but it can actually be used to send any signal.

Isn't it slightly confusing? Maybe there are some historical reasons.

All I know from man kill that this command appeared in Version 3 AT&T UNIX.

share|improve this question
7  
Surely you've answered your own question, the command originated as a means to terminate processes - a long time ago (historical reasons). Once you have a tool that sends signals its almost inevitable that it will get repurposed... –  Murph May 30 '12 at 8:11
2  
(hyperbole) Although I have very little experience with straight Unix, could it be related to the brevity of command names? Most commands have very short names "man", "ls", "cd" "mkdir" for instance. Maybe it's related to the 80 column limit for terminals. Again, I can't be sure as I've not got a huge amount of experience with straight Unix –  Jamie Taylor May 30 '12 at 8:13
2  
@JamieTaylor: I think the main reason for short command names is lazyness. We don't like to type much. I recently learned that cd used to be called chdir, which is definitely insanity! 5 characters for such a common operation? I know people who alias ls to l ;-) –  Joachim Sauer May 30 '12 at 8:32
1  
Because the programmers were too lazy to type in assassinate each time they used it –  briddums Jun 7 '12 at 14:16
1  
@shabunc - Thanks, I can see how the order of my answer might have been misleading, so I've re-ordered it to make it a more direct answer. –  Mark Booth Jun 7 '12 at 15:12

3 Answers 3

up vote 20 down vote accepted

Originally, the kill command could only kill a process, only later was kill enhanced to allow you to send any signal.

Since version 7 of Unix (1979) the default has been to signal the process in a way which can be caught and either handled gracefully or ignored (by sending a SIGTERM signal), but it can also be used to pull the rug out from under a process (a kill -9 sends a SIGKILL signal which cannot be caught and thus cannot be ignored).

Background

Computing, and Unix in particular, is rife with metaphor.

The main metaphor for processes is that of a living thing which is born, lives and dies.

In Unix all processes except init have parents, and any process which spawns other processes has children. Processes may become orphaned (if their parent dies) and can even become zombies, if they hang around after their death.

Thus, the kill command fits in with this metaphor.

Unix Archaeology

From the manual page from version 4 of Unix (the version where kill was introduced, along with ps) we find:

NAME
        kill - do in an unwanted process
SYNOPSIS
        kill processid ...
DESCRIPTION
        Kills the specified processes.
        The processid of each asynchronous process
        started with `&' is reported by the shell.
        Processid's can also be found by using ps (I).

        The killed process must have
        been started from the same typewriter
        as the current user, unless
        he is the superuser.
SEE ALSO
        ps(I), sh(I)

I particularly like the final section of this man page:

BUGS
        Clearly people should only be allowed to kill
        processes owned by them, and having the same typewriter
        is neither necessary nor sufficient.

By the time sixth edition had come around, the kill command had already been overloaded to allow any signal to be sent.

From the manual page from version 6 of Unix:

If a signal number preceded by - is given
as first argument, that signal is sent instead of
kill (see signal (II)).

The default though was to send a signal 9, as signal 15 did not yet exist (see the signal(2) man page for v6).

It was only with version 7 of Unix that signal 15 was introduced (see see the signal(2) man page for v7) and kill switched to that rather than using signal 9.

share|improve this answer
    
How does SIGHUP fit with your metaphor? That's what the OP is asking. –  Gaius Jun 7 '12 at 8:47
    
While I certainly agree about the metaphor point, your introduction about kill only being able to send signal 15 in Unix version 7 is incorrect. Have a look at the kill manual page in plan9.bell-labs.com/7thEdMan/v7vol1.pdf Earlier versions were also likely able to send any signal, although I have no reference yet to provide. –  jlliagre Jun 7 '12 at 15:30
1  
@jlliagre - It's a shame there are no man pages for V5 of unix, but knowing that V4 definitely didn't support specifying the signal should be enough for even the most pedantic. *8') –  Mark Booth Jun 7 '12 at 18:36

This is Unix.

kill is able not to kill a process.

mv is able to rename and not only move files from one place to another.

touch is able to create a file and not only change its last modification time.

od means Octal Dump, but is able to perform many more kinds of dumps.

yes is able to output no.

More exotic:

grep is named after the ed command that perform the same operation: g/re/p

awk is named after its authors: Aho, Weinberger and Kernighan.

yacc means Yet Another Compiler Compiler. Note that bison is the GNU yacc.

share|improve this answer
15  
To be entirely fair, the difference between moving and renaming a file is rather arbitrary. "Renaming" a file is just moving it to a different location which happens to be in the same directory. –  Tikhon Jelvis May 30 '12 at 9:22
    
+1. Great answer! –  Doc Brown May 30 '12 at 11:09
    
mv create a new inode(?) and moves the reference to the file contents from the old inode to the new one. Except when it's not on the same device. Then it copies the contents and removes the inode. –  Paul Jun 7 '12 at 15:19
3  
What's also fun is that you can mv/rm a file which is open by another process. The other process still has a reference to the file contents. Different from other OS –  Paul Jun 7 '12 at 15:19
    
+1 for confusing me with yes also meaning no –  Jamie Taylor Jun 7 '12 at 15:39

Unix version 7 kill manual page states:

kill - terminate a process with extreme prejudice

and

This will kill processes that do not catch the signal; in particular `kill -9 ...'  is a sure kill.

There would be good no reason not to call that command kill which is certainly the best metaphor available.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.