Shell ne montre pas les commandes tapées, "reset" fonctionne, mais que s'est-il passé ?

Lors de l'exécution d'un Shell ou de la plupart des programmes dans un Shell, tout ce que vous tapez est renvoyé en écho au terminal de l'utilisateur par le sous-système tty du noyau. Il y a d'autres manipulations spéciales, aussi, pour les caractères d'effacement, Ctrl+R , Ctrl+Z et ainsi de suite.

Certains programmes, (les éditeurs en particulier) qui s'exécutent à partir d'une ligne de commande n'ont pas besoin ou ne veulent pas de cela. Pour cette raison, ils signalent au noyau par un message Appel IOCTL contre le périphérique tty (terminal) qu'ils ne veulent pas de ce comportement. Ils ne veulent pas non plus que les caractères spéciaux fassent des choses spéciales. Au lieu de cela, ils demandent au noyau un mode "brut". En particulier, les éditeurs comme vim désactivent divers "paramètres d'écho". Tout ceci s'applique aux terminaux tty réels sur les lignes série d'un ordinateur, ou aux terminaux virtuels à l'adresse suivante Alt+Ctrl+F4 ou les terminaux vraiment virtuels que vous obtenez lorsque vous exécutez quelque chose comme gnome-terminal sous une interface graphique.

De tels programmes sont censés réinitialiser tous les modes qu'ils modifient sur le tty virtuel qu'ils utilisent avant de quitter, soit en entrant une commande de l'éditeur quit ou en prenant un signal (de Ctrl+C ) par exemple.

S'ils ne le font pas correctement, le tty reste dans l'état bizarre que vous avez découvert. Puisque les programmes peuvent échouer à réinitialiser le terminal, la fonction reset La commande a été écrite pour permettre à l'utilisateur de récupérer.

Je suppose que l'interruption perturbe le logiciel Python que vous exécutez. Je suppose que ce programme n'a pas la possibilité de réinitialiser le terminal, ou qu'il ne le fait tout simplement pas.

Dans le cas de vim, lorsque j'exécute votre exemple, j'obtiens le même comportement que celui que vous décrivez. Je vois également un message "Vim : Warning : Input is not from a terminal" (Il disparaît quand on réinitialise). C'est parce que vim n'est pas lancé normalement à partir du Shell. Au lieu de cela, le programme ' grep et xargs Les commandes ' ont utilisé l'entrée standard, normalement occupée par le tty, pour transmettre les noms de fichiers de l'application grep tto xargs .

Dans votre sortie affichée de stty -a on peut voir "-echo", confirmant également que c'est le problème. Si vous deviez tuer vim de manière à ce qu'il ne puisse pas gérer le signal avec élégance, vous verriez probablement le même problème.

Le problème est décrit ailleurs à l'adresse suivante https://stackoverflow.com/questions/3852616/xargs-with-command-that-open-editor-leaves-Shell-en-état de délire .

Une solution pour le cas de vim est d'éviter xargs et d'utiliser à la place :

vim $(grep foo * -l)

Ici la liste des fichiers est construite par le Shell, comme elle l'avait été par xargs, mais le Shell appelle vim, qui est directement connecté au tty. Il y a un message d'avertissement envoyé au fichier de sortie des erreurs, et vim définit et réinitialise les paramètres du tty correctement.

Une alternative à reset qui n'efface pas l'écran est stty sane .

Plus de références aquí et un autre intéressant aquí . Une autre solution intéressante est donnée dans une réponse à https://stackoverflow.com/questions/8228831/why-does-locate-filename-xargs-vim-cause-strange-terminal-behaviour .