Perché non è possibile uscire con Cc?

Il programma ed, un editor di testo minimo, non può essere chiuso inviandogli un interrupt tramite Ctrl- C, invece stampando il messaggio di errore "?" alla console. Perché non edesce solo quando riceve l'interrupt? Sicuramente non c'è motivo per cui un messaggio di errore criptico sia più utile qui che semplicemente uscire. Questo comportamento porta molti nuovi utenti nel seguente tipo di interazione:

$ ed
hello
?
help
?
exit
?
quit
?
^C
?
^C
?
?
?
^D
$ su
# rm -f /bin/ed

Uno spreco così tragico, facilmente evitabile se fosse edsemplicemente accettato di essere interrotto.

Un altro programma testardo che mostra un comportamento simile è lessche non sembra avere molte ragioni per ignorarlo C-c. Perché questi programmi non danno solo un suggerimento?

Ctrl+ Cinvia SIGINT . L'azione convenzionale per SIGINT è di tornare al ciclo di livello superiore di un programma, annullando il comando corrente ed entrando in una modalità in cui il programma attende il comando successivo. Solo i programmi non interattivi dovrebbero morire di SIGINT.

Quindi è naturale che Ctrl+ Cnon uccida, ma lo ritorni al suo ciclo di livello superiore. Ctrl+ Cinterrompe la riga di input corrente e ritorna al prompt ed.

Lo stesso vale per meno: Ctrl+ Cinterrompe il comando corrente e riporta al prompt dei comandi.

Per motivi storici, ed ignora SIGQUIT ( Ctrl+ \). Le applicazioni normali non dovrebbero catturare questo segnale e consentire a se stesse di essere terminate, con un core dump se abilitato.

Il codice sorgente Unix V7ed(1) è un programma C primitivo di 1.762 righe con pochi commenti, uno dei quali è questo commento di intestazione altamente illuminante:

/*
 * Editor
 */

Dato che il codice sorgente stesso non fornisce alcuna logica, lo otterrai solo dall'autore del programma.

edè stato originariamente scritto da Ken Thompson nell'assemblea PDP-11 , ma in realtà avresti bisogno di parlare con chiunque lo portasse a C. Potrebbe essere stato Dennis Ritchie , da quando ha creato C per Unix, ed è stato uno dei tanti che hanno usato C per rendere Unix portabile su macchine non PDP. Il dottor Ritchie non è più in giro per rispondere a tali domande.

La mia lettura del codice suggerisce che è stato fatto per cercare di preservare il contenuto della copia in-core del documento modificato. Noterai che anche altri editor di testo non muoiono Ctrl-C.

Ecco cosa edfa su Ctrl-C:

onintr()
{
    signal(SIGINT, onintr);
    putchr('\n');
    lastc = '\n';
    error(Q);
}

(Sì, K&R C. Non abbiamo bisogno di specificatori del tipo restituito di Steenkin o dichiarazioni di parametri.)

Tradotto in inglese ed,:

1. Registra nuovamente il gestore del segnale.

   (Unix non ha ricevuto segnali di auto-reset fino a 4.3BSD , a metà degli anni '80.)

2. Scrive una nuova riga e ricorda di averlo fatto tramite la variabile globale lastc.

   ( ed.cha circa sessanta variabili globali).

3. Chiama la error()funzione, che notoriamente fa poco più che stampare ?, dal punto di vista dell'utente.

In altre parole, sta dicendo: "Non volevi davvero farlo, vero?"

ed, come altri programmi interattivi, usa Ctrl+ Cper interrompere le attività del programma stesso.
Questo è molto simile al caso normale, in cui interrompe un'attività in esecuzione nella shell: un comando.

Dal punto di vista dell'utente, entrambe le varianti sono molto simili. La gestione del segnale è diversa: nel solito caso, il segnale SIGINTviene inviato al processo in primo piano, un comando in esecuzione e il comando lo gestisce uscendo.
Nel caso di ed, il segnale viene inviato al processo in primo piano, l' edistanza. Se è in esecuzione un'attività ed, viene interrotta e viene visualizzato il prompt. Se non è in esecuzione alcuna attività, non viene modificato nulla.

Nota come anche una shell non esce su Ctrl+ C, proprio come ed. E che esce su Ctrl+ D. Ancora una volta, proprio comeed

Ci sono tre segnali che si edpreoccupano:

1. INT
2. HUP
3. QUIT

La specifica POSIX died dice quanto segue su questi:

SIGINT

L' edutilità deve interrompere l'attività corrente, scrivere la stringa ?\nsull'output standard e tornare alla modalità di comando (consultare la sezione DESCRIZIONE ESTESA).

SIGHUP

Se il buffer non è vuoto ed è cambiato dall'ultima scrittura, l' edutilità deve tentare di scrivere una copia del buffer in un file. Innanzitutto, ed.hupdeve essere utilizzato il file indicato nella directory corrente; in caso contrario, verrà utilizzato il file indicato ed.hupnella directory indicata dalla HOMEvariabile d'ambiente. In ogni caso, l' edutilità deve uscire senza scrivere il file nel percorso attualmente memorizzato e senza tornare alla modalità di comando.

SIGQUIT

L' edutilità deve ignorare questo evento.

Quindi, qualunque implementazione edtu stia usando, è conforme alle specifiche POSIX per quanto riguarda il INTsegnale (che è ciò che Ctrl+Cinvia).

A questo proposito, l'editor si comporta come una shell interattiva, che inoltre non termina alla ricezione del INTsegnale. Altri editor, come vie nanofanno la stessa cosa.