Perché il comando "kill" si chiama così?


16

Perché è stato deciso di chiamare il killcomando "uccidi"?

Voglio dire, sì, questa utility viene spesso utilizzata per terminare i processi, ma in realtà può essere utilizzata per inviare qualsiasi segnale.

Non è leggermente confuso? Forse ci sono alcuni motivi storici.

Tutto quello che so da man killquesto comando è apparso nella versione 3 AT&T UNIX.


8
Sicuramente hai risposto alla tua domanda, il comando è nato come mezzo per terminare i processi - molto tempo fa (ragioni storiche). Una volta che hai uno strumento che invia segnali è quasi inevitabile che venga riproposto ...
Murph

2
(iperbole) Anche se ho poca esperienza con Unix, potrebbe essere correlato alla brevità dei nomi dei comandi? La maggior parte dei comandi ha nomi molto brevi "man", "ls", "cd" "mkdir" per esempio. Forse è correlato al limite di 80 colonne per i terminali. Ancora una volta, non posso essere sicuro perché non ho una grande esperienza con Unix etero
Jamie Taylor,

2
@JamieTaylor: Penso che il motivo principale per i nomi brevi dei comandi sia la pigrizia. Non ci piace scrivere molto. Recentemente ho imparato che cdsi chiamava chdir, il che è sicuramente follia! 5 caratteri per un'operazione così comune? Conosco persone che alias lsa l;-)
Joachim Sauer

3
Perché i programmatori erano troppo pigri per digitare assassinateogni volta che lo usavano
briddums

1
@shabunc - Grazie, posso vedere come l'ordine della mia risposta potrebbe essere stato fuorviante, quindi l'ho riordinato per renderlo una risposta più diretta.
Mark Booth,

Risposte:


22

Inizialmente, il killcomando poteva solo terminare un processo, solo in seguito è stato killmigliorato per consentire di inviare qualsiasi segnale.

Dalla versione 7 di Unix (1979) il default è stato quello di segnalare il processo in un modo che può essere catturato e gestito con grazia o ignorato (inviando un segnale SIGTERM ), ma può anche essere usato per estrarre il tappeto da sotto un processo (a kill -9invia un segnale SIGKILL che non può essere catturato e quindi non può essere ignorato).

sfondo

L'informatica e Unix in particolare sono pieni di metafora.

La metafora principale dei processi è quella di un essere vivente che nasce, vive e muore.

In Unix tutti i processi tranne init hanno dei genitori e ogni processo che genera altri processi ha figli . I processi possono diventare orfani (se il loro genitore muore) e possono persino diventare zombi , se rimangono in giro dopo la loro morte.

Pertanto, il killcomando si adatta a questa metafora.

Unix Archaeology

Dalla pagina di manuale della versione 4 di Unix (la versione in cui è killstata introdotta, insieme a ps) troviamo:

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)

Mi piace particolarmente la sezione finale di questa pagina man:

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

Al momento della quinta edizione, il killcomando era già stato sovraccaricato per consentire l'invio di qualsiasi segnale.

Dal manuale dei programmatori Unix, quinta edizione (p70):

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

L'impostazione predefinita era di inviare un segnale 9, poiché il segnale 15 non esisteva ancora (vedi p150).

Con la versione 6 la killpagina man non menzionava più lo stesso bug della macchina da scrivere .

Fu solo con la versione 7 di Unix che fu introdotto il segnale 15 (vedere le pagine man del segnale (2) e kill (1) per v7) e si killpassò a quello invece di usare il segnale 9.


26

Questo è Unix.

kill è in grado di non uccidere un processo.

mv è in grado di rinominare e non solo spostare i file da una posizione all'altra.

touch è in grado di creare un file e non solo modificare l'ora dell'ultima modifica.

od significa Dump ottale, ma è in grado di eseguire molti più tipi di dump.

yes è in grado di produrre n.

Più esotico:

grepprende il nome dal edcomando che esegue la stessa operazione:g/re/p

awk prende il nome dai suoi autori: Aho, Weinberger e Kernighan.

yaccsignifica Yet Another Compiler Compiler. Nota che bisonè GNU yacc.


17
Per essere del tutto onesti, la differenza tra spostare e rinominare un file è piuttosto arbitraria. "Rinomina" un file lo sta semplicemente spostando in una posizione diversa che si trova nella stessa directory.
Tikhon Jelvis,

mv crea un nuovo inode (?) e sposta il riferimento al contenuto del file dal vecchio inode a quello nuovo. Tranne quando non è sullo stesso dispositivo. Quindi copia il contenuto e rimuove l'inode.
Paul,

3
La cosa divertente è anche che puoi mv / rm un file che è aperto da un altro processo. L'altro processo ha ancora un riferimento al contenuto del file. Diverso da altri sistemi operativi
Paul

+1 per confondermi con sì significa anche no
Jamie Taylor

@Paul - Il mio Unix è piuttosto arrugginito, ma penso che tu l'abbia un po 'arretrato. L'inode è l'identificatore univoco del file. Quindi, nello stesso caso dispositivo, viene creata una nuova voce di directory che punta allo stesso inode e quindi la voce di directory originale viene rimossa. Mi chiedo perché Apple non abbia citato in giudizio qualcuno per "inode".
OldFart

0

La pagina del manuale di uccisione della versione 7 di Unix afferma:

kill - terminate a process with extreme prejudice

e

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

Non ci sarebbe alcun motivo per non chiamare quel comando kill che è sicuramente la migliore metafora disponibile.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.