18

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
shabunc
  • 2,424
  • 2
  • 20
  • 27
  • 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 '12 at 08: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 08: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 08:32
  • @MarkBooth, it looks like I've misread you answer, sorry for that. Your answer is indeed the answer - originally kill send only SIGTERM. Will mark you answer, as for mouviciel - thank you, you deserve your 13 points, but my vote goes to Mark. – shabunc Jun 07 '12 at 14:16
  • 4
    Because the programmers were too lazy to type in `assassinate` each time they used it – briddums Jun 07 '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 07 '12 at 15:12
  • @Joachim: chdir still works in Windows. It's been there since MS-DOS 1.0. It came from CP/M. My assumption is that it's roots are from the chdir() C function to change directories in your code. CD was created because chdir was too long... – shufler Jun 07 '12 at 22:00
  • @shufler - Which version of CP/M had a `chdir` command? I remember the `user` command to switch between different *user areas* if your disk had been split up that way. Also I seem to remember that directories were only introduced in DOS 2.0, DOS 1.0 didn't even have CP/M's user areas. – Mark Booth Jun 08 '12 at 10:13

3 Answers3

27

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.

mouviciel
  • 15,473
  • 1
  • 37
  • 64
  • 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. – Tikhon Jelvis May 30 '12 at 09: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 07 '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 07 '12 at 15:19
  • +1 for confusing me with yes also meaning no – Jamie Taylor Jun 07 '12 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 07 '12 at 19:51
23

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

Mark Booth
  • 14,214
  • 3
  • 40
  • 79
0

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.

jlliagre
  • 139
  • 3