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.

  • 8
    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, 2012 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 May 30, 2012 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 ;-) May 30, 2012 at 8:32
  • 4
    Because the programmers were too lazy to type in assassinate each time they used it
    – briddums
    Jun 7, 2012 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, 2012 at 15:12

3 Answers 3


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).


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:

        kill - do in an unwanted process
        kill processid ...
        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.
        ps(I), sh(I)

I particularly like the final section of this man page:

        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 fifth edition had come around, the kill command had already been overloaded to allow any signal to be sent.

From the Unix Programmers Manual, Fifth Edition (p70):

If a signal number preceded by "-" is given
as an 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 p150).

With version 6 the kill man page no longer mentioned the same typewriter bug.

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


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.

  • 17
    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. May 30, 2012 at 9:22
  • 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, 2012 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, 2012 at 15:19
  • +1 for confusing me with yes also meaning no Jun 7, 2012 at 15:39
  • @Paul - My Unix is pretty rusty, but I think you have it a little backward. The inode is the unique identifier of the file. So, in the same device case, a new directory entry is created pointing to the same inode and then the original directory entry is removed. I wonder why Apple hasn't sued someone over "inode".
    – OldFart
    Jun 7, 2012 at 19:51

Unix version 7 kill manual page states:

kill - terminate a process with extreme prejudice


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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