Por que o comando "kill" é chamado assim?

Por que foi decidido chamar o killcomando "matar"?

Quero dizer, sim, esse utilitário geralmente é usado para finalizar processos, mas na verdade pode ser usado para enviar qualquer sinal.

Não é um pouco confuso? Talvez haja algumas razões históricas.

Tudo o que sei é man killque esse comando apareceu na versão 3 da AT&T UNIX.

terminology history unix

— shabunc
fonte

Certamente você respondeu sua própria pergunta, o comando se originou como um meio de finalizar processos - há muito tempo (razões históricas). Uma vez que você tem uma ferramenta que envia sinais a sua quase inevitáveis que ele vai ficar reaproveitado ...

— Murph

(hipérbole) Embora eu tenha muito pouca experiência com o Unix direto, isso pode estar relacionado à brevidade dos nomes de comando? A maioria dos comandos possui nomes muito curtos "man", "ls", "cd" "mkdir", por exemplo. Talvez esteja relacionado ao limite de 80 colunas para terminais. Mais uma vez, eu não posso ter certeza que eu não tenho uma enorme quantidade de experiência com Unix reta

— Jamie Taylor

@ JamieTaylor: Eu acho que a principal razão para nomes curtos de comando é a preguiça. Não gostamos de digitar muito. Eu aprendi recentemente que cdcostumava ser chamado chdir, o que é definitivamente loucura! 5 caracteres para uma operação tão comum? Conheço pessoas que apelido lspara l;-)

— Joachim Sauer

Porque os programadores estavam com preguiça de digitar assassinatecada vez que o usou

— briddums

@shabunc - Obrigado, posso ver como a ordem da minha resposta pode ter sido enganosa, então reordenei para torná-la uma resposta mais direta.

— Mark Booth

Respostas:

Originalmente, o killcomando só podia matar um processo, apenas mais tarde foi killaprimorado para permitir o envio de qualquer sinal.

Desde a versão 7 do Unix (1979), o padrão é sinalizar o processo de uma maneira que possa ser capturada e manipulada normalmente ou ignorada (enviando um sinal SIGTERM ), mas também pode ser usada para puxar o tapete de baixo para baixo. um processo (a kill -9envia um sinal SIGKILL que não pode ser capturado e, portanto, não pode ser ignorado).

fundo

A computação, e o Unix em particular, é repleto de metáforas.

A principal metáfora dos processos é a de um ser vivo que nasce, vive e morre.

No Unix, todos os processos, exceto o init, têm pais , e qualquer processo que gera outros processos tem filhos . Os processos podem tornar-se órfãos (se seus pais morrerem) e podem até se tornar zumbis , se ficarem juntos após a morte.

Assim, o killcomando se encaixa nessa metáfora.

Arqueologia Unix

Na página de manual da versão 4 do Unix (a versão em que killfoi apresentada, juntamente com 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)

Eu particularmente gosto da seção final desta 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.

Quando a quinta edição chegou, o killcomando já estava sobrecarregado para permitir que qualquer sinal fosse enviado.

No Manual do Programador Unix, Quinta Edição (p70):

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

O padrão, porém, era enviar um sinal 9, pois o sinal 15 ainda não existia (consulte a página 150).

Com a versão 6, a killpágina de manual não mencionava mais o mesmo bug da máquina de escrever .

Foi apenas na versão 7 do Unix que o sinal 15 foi introduzido (consulte as páginas do manual do sinal (2) e kill (1) da v7) e killmudou para isso em vez de usar o sinal 9.

— Mark Booth
fonte

Este é o Unix.

kill é capaz de não matar um processo.

mv é capaz de renomear e não apenas mover arquivos de um lugar para outro.

touch é capaz de criar um arquivo e não apenas alterar sua última hora de modificação.

od significa Octal Dump, mas é capaz de executar muitos outros tipos de dump.

yes é capaz de produzir não.

Mais exótico:

grepé nomeado após o edcomando que executa a mesma operação:g/re/p

awk tem o nome de seus autores: Aho, Weinberger e Kernighan.

yaccsignifica ainda outro compilador. Note que bisoné o GNU yacc.

— mouviciel
fonte

Para ser totalmente justo, a diferença entre mover e renomear um arquivo é bastante arbitrária. "Renomear" um arquivo está apenas movendo-o para um local diferente, que por acaso está no mesmo diretório.

— Tikhon Jelvis

mv cria um novo inode (?) e move a referência para o conteúdo do arquivo do inode antigo para o novo. Exceto quando não estiver no mesmo dispositivo. Em seguida, ele copia o conteúdo e remove o inode.

— Paulo

O que também é divertido é que você pode mv / rm um arquivo que é aberto por outro processo. O outro processo ainda tem uma referência ao conteúdo do arquivo. Diferente de outros sistemas operacionais

— Paul

+1 para me confundindo com sim também não significa

— Jamie Taylor

@Paul - Meu Unix está muito enferrujado, mas acho que você o tem um pouco para trás. O inode é o identificador exclusivo do arquivo. Portanto, no mesmo caso de dispositivo, uma nova entrada de diretório é criada apontando para o mesmo inode e a entrada de diretório original é removida. Eu me pergunto por que a Apple não processou alguém por "inode".

— precisa saber é o seguinte

A página 7 do Unix mata os estados da página de manual :

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.

Não haveria razão para não chamar esse comando de matar, que é certamente a melhor metáfora disponível.

— jlliagre
fonte