¿Por qué se llama así al comando "matar"?


16

¿Por qué se decidió llamar al killcomando "matar"?

Quiero decir, sí, esta utilidad a menudo se usa para terminar procesos, pero en realidad se puede usar para enviar cualquier señal.

¿No es un poco confuso? Tal vez hay algunas razones históricas.

Todo lo que sé es man killque este comando apareció en la Versión 3 de AT&T UNIX.


8
Seguramente ha respondido a su propia pregunta, el comando se originó como un medio para finalizar procesos, hace mucho tiempo (razones históricas). Una vez que tiene una herramienta que envía señales, es casi inevitable que se reutilice ...
Murph

2
(hipérbole) Aunque tengo muy poca experiencia con Unix directo, ¿podría estar relacionado con la brevedad de los nombres de comandos? La mayoría de los comandos tienen nombres muy cortos "man", "ls", "cd" "mkdir", por ejemplo. Tal vez esté relacionado con el límite de 80 columnas para terminales. Una vez más, no puedo estar seguro, ya que no tengo mucha experiencia con Unix directo
Jamie Taylor

2
@JamieTaylor: Creo que la razón principal de los nombres de comandos cortos es la pereza. No nos gusta escribir mucho. Hace poco aprendí que cdsolía llamarse chdir, lo que definitivamente es una locura. ¿5 caracteres para una operación tan común? Conozco personas que alias lsa l;-)
Joachim Sauer

3
Debido a que los programadores eran demasiado vagos para escribir assassinatecada vez que lo usaban
briddums el

1
@shabunc - Gracias, puedo ver cómo el orden de mi respuesta puede haber sido engañoso, así que lo he reordenado para que sea una respuesta más directa.
Mark Booth

Respuestas:


22

Originalmente, el killcomando solo podía matar un proceso, solo más tarde se killmejoró para permitirle enviar cualquier señal.

Desde la versión 7 de Unix (1979), el valor predeterminado ha sido señalar el proceso de una manera que se pueda atrapar y manejar con gracia o ignorar (enviando una señal SIGTERM ), pero también se puede usar para sacar la alfombra de debajo un proceso (a kill -9envía una señal SIGKILL que no se puede capturar y, por lo tanto, no se puede ignorar).

Antecedentes

La informática, y Unix en particular, está plagada de metáforas.

La metáfora principal de los procesos es la de un ser vivo que nace, vive y muere.

En Unix, todos los procesos excepto init tienen padres , y cualquier proceso que genera otros procesos tiene hijos . Los procesos pueden quedar huérfanos (si sus padres mueren) e incluso pueden convertirse en zombis , si se quedan después de su muerte.

Por lo tanto, el killcomando encaja con esta metáfora.

Arqueología de Unix

En la página del manual de la versión 4 de Unix (la versión donde killse introdujo, junto con ps) encontramos:

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)

Me gusta especialmente la sección final de esta página de manual:

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

Cuando llegó la quinta edición, el killcomando ya se había sobrecargado para permitir que se enviara cualquier señal.

Del Manual de Programadores de Unix, Quinta Edición (p70):

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

Sin embargo, el valor predeterminado era enviar una señal 9, ya que la señal 15 aún no existía (ver p150).

Con la versión 6, la killpágina de manual ya no menciona la misma máquina de escribir error de .

Fue solo con la versión 7 de Unix que se introdujo la señal 15 (consulte las páginas de manual de la señal (2) y kill (1) para v7) y se killcambió a eso en lugar de usar la señal 9.


26

Este es Unix.

kill es capaz de no matar un proceso.

mv es capaz de cambiar el nombre y no solo mover archivos de un lugar a otro.

touch es capaz de crear un archivo y no solo cambiar su última hora de modificación.

od significa volcado octal, pero puede realizar muchos más tipos de volcados.

yes es capaz de dar salida no.

Más exótico:

greplleva el nombre del edcomando que realiza la misma operación:g/re/p

awk lleva el nombre de sus autores: Aho, Weinberger y Kernighan.

yaccsignifica otro compilador compilador. Tenga en cuenta que bisones el GNU yacc.


17
Para ser completamente justos, la diferencia entre mover y renombrar un archivo es bastante arbitraria. "Cambiar el nombre" de un archivo es simplemente moverlo a una ubicación diferente que está en el mismo directorio.
Tikhon Jelvis

mv crea un nuevo inodo (?) y mueve la referencia al contenido del archivo del antiguo inodo al nuevo. Excepto cuando no está en el mismo dispositivo. Luego copia el contenido y elimina el inodo.
Paul

3
Lo que también es divertido es que puedes mv / rm un archivo que está abierto por otro proceso. El otro proceso todavía tiene una referencia al contenido del archivo. Diferente de otros sistemas operativos
Paul

+1 por confundirme con sí también significa no
Jamie Taylor

@Paul - Mi Unix está bastante oxidado, pero creo que lo tienes un poco al revés. El inodo es el identificador único del archivo. Entonces, en el mismo caso del dispositivo, se crea una nueva entrada de directorio apuntando al mismo inodo y luego se elimina la entrada de directorio original. Me pregunto por qué Apple no ha demandado a alguien por "inodo".
OldFart

0

La página de manual de kill de Unix versión 7 dice:

kill - terminate a process with extreme prejudice

y

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

No habría ningún motivo para no llamar a ese comando kill, que sin duda es la mejor metáfora disponible.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.