Si vous appuyez plusieurs fois sur ctrl-c, le programme en cours se ferme plus rapidement?

41

Je commence souvent à lire un fichier volumineux, puis je veux quitter au bout d'un moment, mais il y a un décalage entre l'appui sur
Ctrl+ Cet l'arrêt du programme. Existe-t-il une chance de réduire le décalage en appuyant plusieurs fois sur la touche Ctrl+ C? Ou est-ce que je gaspille mes touches?

process kill signals

— Le chat
source

J'ai remarqué que lors de l'exécution d'un processus appelant divers processus enfants, Ctrl-C interrompait parfois l'enfant en cours d'exécution, mais pas le processus parent. Cela est vrai dans bash, mais pas le cas dans zshlequel ferme toujours le parent. C'est l'une des raisons pour lesquelles j'aime bien zsh.

— Joeytwiddle

17

Oui, comme si vous appuyiez plusieurs fois sur le bouton d'ascenseur ou le bouton de marche transversale, l'ascenseur arrivera plus tôt ou le voyant deviendra vert plus rapidement.

— Michael

3

Oui, tout comme les boutons d'ascenseur et de passage pour piétons, CTRL-C peut également devenir collant, rouillé ou développer des connexions douteuses. Presser plusieurs fois est une bonne tactique, car une seule presse doit s'inscrire pour que l'ascenseur vienne, que le panneau de signalisation s'allume ou que le programme se ferme.

— hippietrail

1

@hippietrail mais votre shell imprimera ^Cquand il enregistrera la presse (au moins bash le fera)

— wchargin

1

Pour ce que cela vaut, je ne considère pas que gaspiller mes touches est une gâchis - je considère que cela évacue une certaine frustration de manière non dommageable. ( D' habitude , je l' ai frappé 2-3 fois, mais c'est en partie parce que je « grandi sur » bornes attachées sur des lignes téléphoniques où on ne pouvait pas toujours compter sur chaque frappe unique pour atteindre la machine.)

— keshlam

35

Après la première Ctrl-C, le programme recevra SIGINTet commencera généralement le nettoyage (suppression des fichiers tmp, fermeture des sockets, etc.). Si vous frappez de Ctrl-Cnouveau pendant que cela se produit , il peut arriver que vous interrompiez la routine de nettoyage (c’est-à-dire que le signal supplémentaire risque d’ être exploité au lieu d’être laissé seul), laissant ainsi un désordre derrière vous. Bien que ce ne soit généralement pas le cas, le plus souvent, les signaux supplémentaires sont envoyés aprèsle processus est terminé (en raison des retards inhérents à l'interaction de l'opérateur avec le système). Cela signifie que les signaux sont reçus par un autre processus (souvent shell, mais pas toujours). Si ce destinataire ne gère pas correctement ce signal (comme le fait d'habitude Shell - voir la réponse de Jenny D), vous risquez d'être désagréablement surpris par le résultat de cette action.

— John1024
source

Pourquoi devrait-il interrompre la routine de nettoyage? C'est juste un autre signal INTque le processus reçoit.

— chaos

4

@chaos Pourquoi devrait-il? Si la routine de nettoyage est suspendue et que vous voulez l’arrêter, cela devrait être le cas. Cela fonctionne-t-il réellement de cette façon? Oui, assez souvent Vous pouvez le démontrer simplement: créez un script bash avec une seule ligne trap "sleep 20 || echo clean up cancelled!" EXIT ; sleep 10. Exécutez le script et appuyez deux fois sur ctrl-C. Vous verrez que le second ctrl-C est passé à la routine "clean up" (dans l'instruction trap) et termine sa sleepcommande.

— John1024

1

@ John1024 Ah, maintenant je le vois. Merci pour l'extrait de script ^^ Mais le nettoyage n'est pas annulé, voir: trap "sleep 20 || echo clean up cancelled!; sleep 10; echo 'but continued'" EXIT ; sleep 10ce sont juste les sleepcommandes qui reçoivent les signaux. Nous avions tous les deux tort xD

— chaos

2

C'est faux. La transmission du signal est synchrone. Si isigest activé, dès que CTRL-C est pressé et reçu par le noyau (pour un émulateur de terminal, dès que l'émulateur de terminal l'écrit sur le côté maître du pseudo-terminal), le signal SIGINT est envoyé à tous les processus dans le groupe de processus de premier plan du terminal. Il est peut-être bloqué à cet endroit, mais il ne sera pas transmis ultérieurement à un autre processus. Même si la mémoire tampon du terminal est saturée (les applications n'ont lu aucune des choses que vous avez saisies), le CTRL-C saute dans la file d'attente.

— Stéphane Chazelas

1

Oui, à titre d’exemple, VLC interprète plusieurs signaux Ctrl + C comme un moyen de quitter malpropre, alors qu’un simple Ctrl + C tentera de quitter proprement.

— Jeremy Visser

11

Vous les gaspillez. Tout ce qui se passe, c'est qu'une fois que le serveur a terminé avec la sortie d'écran, il en reçoit plusieurs Ctrl-C. Le premier sera utilisé pour tuer le processus, et les suivants se retrouveront dans votre shell, qui ressemblera à quelque chose comme:

[user@server]$ ^C
[user@server]$ ^C
[user@server]$ ^C
[user@server]$ ^C
[user@server]$ ^C
[user@server]$

— Jenny D
source

6

Le processus ne se ferme pas nécessairement lors de l'envoi d'un SIGINT. Il peut rester en vie indéfiniment et faire quelque chose de différent chaque fois que vous appuyez sur Ctrl + C.

— Brian Gordon

Vrai. Je faisais des hypothèses sur la façon dont l'utilisateur lisait le fichier.

— Jenny D

5

Réponse courte : Si le processus y réagit.

Réponse longue : lorsque vous appuyez sur ctrl+, cle noyau envoie un signal au processus. Quel signal peut être déterminé par la commande suivante:

user@host:~# stty -a | grep -i "\^C"
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;

Voir la page de manuel de stty:

   intr CHAR
          CHAR will send an interrupt signal

C'est le signal INT, également appelé numéro 2. Lorsque le processus a un gestionnaire de signal, il peut réagir à cela. La plupart des processus effectuent certains travaux de nettoyage pour aboutir.

— le chaos
source

Ctrl-Z envoie généralement SIGTSTP qui peut être manipulé (contrairement à SIGSTOP).

— Peter

4

Non, ce n'est pas le shell qui envoie le SIGINT au processus. C'est le kernel(la discipline de ligne du terminal, le pilote de terminal) qui envoie SIGINT à chaque processus du groupe de processus de premier plan du terminal.

— Stéphane Chazelas

Les futurs lecteurs, voir également unix.stackexchange.com/a/120071/135943 .

— Wildcard

4

Tu as raison. Les touches sont gaspillées. Lorsque vous appuyez sur le bouton Crtl+Cet que celui-ci est détecté, des ressources doivent être effacées, ce qui explique le temps nécessaire. Le seul cas où je sache où il Ctrl+Cest nécessaire d’ appuyer est lorsque vous souhaitez annuler un processus de mise à jour de Yum, où Yum vous oblige à appuyer Ctrl+Cdeux fois pour confirmer que vous souhaitez réellement annuler.

— Nav
source

2

Bien qu’un seul Ctrl-Csoit nécessaire dans le cas général, il existe certaines situations où cela peut être nécessaire. Python, par exemple, intercepte Ctrl-Clorsqu’un nouveau thread est créé. Ainsi, en cas de problème lors du démarrage de nombreux threads, il est nécessaire de le renvoyer à plusieurs reprises afin qu’il parvienne au pythonprocessus parent sans être ignoré. pris.

— Patrick Collins
source

1

Cela m’arrive de temps en temps lorsque je crée des scripts python multi-threadés / traités. Parfois, plusieurs presses sont nécessaires avant que le processus principal ne soit tué.

— Leo

0

Je dois toujours appuyer Ctrlcplusieurs fois. Je ne l'ai jamais fait répondre à la première presse et je dois l'utiliser plusieurs fois jusqu'à ce que le système se rende compte qu'il y a un Ctrlcenvoi. On dirait qu’il en manque ou en perd la plupart.

— utilisateur280568
source