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.
kill command fits in with this metaphor.
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.
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 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.