Voui, j'adore les Linux qui s'installent rapidement et facilement comme Debian par exemple. A force de bidouiller dans tous les coins, je casse mon beau système tout les mois environ et c'est vraiment bien de pouvoir le remettre en état (j'ai d'ailleurs de très bons scripts pour ça :-P. Dernièrement, j'ai eu un bogue vraiment classe avec une commande toute bête :
cat /dev/urandom > /tmp/test_bytes
C'est ce genre de bug parfaitement incompréhensible (du moins pour moi), qui fait toute la poésie de Linux :-P
Quelqu'un aurait une explication rationnelle (ou pas) ?
Édit : Je précise que en une fraction de seconde après avoir lancé la commande, j'ai fait un ctrl-c histoire de na pas avoir un fichier très (trop) long.
# Ce sont eux
Posté par Marotte ⛧ . Évalué à 3.
Certaines séquences produites par /dev/urandom lance des connexions avec eux, des fois ils répondent, comme ici.
Tu peux taper
setterm -reset(ce sera automatiquement traduit dans leur langue au moment où tu le tapes) et faire entrée. Ça veut dire : « Non merci je ne veux pas parler avec toi, rends moi mon terminal s’il te plait. »Ils sont très gentils et te rendent toujours ton terminal.
[^] # Re: Ce sont eux
Posté par wismerhill . Évalué à 4.
Sauf qu'il avait redirigé la sortie dans un fichier, donc il ne devrait y avoir eu aucun effet sur le terminal.
[^] # Re: Ce sont eux
Posté par DaVi . Évalué à 1. Dernière modification le 06 août 2016 à 21:33.
Oui, je connais la "commande magique", ce que je voulais savoir, c'est d'où venait ce comportement (pourquoi ce langage venu d’ailleurs, pourquoi ?).
Oh, et puis ça va, cette fois je n'ai pas eu à réinstaller ma Debian, juste un ctrl-c & ctrl-T.
http://github.com/DaudrVignieCharles/
[^] # Re: Ce sont eux
Posté par Marotte ⛧ . Évalué à 2.
Je pense que ça a effectivement un lien avec le fait que tu aies fait Ctrl+c pour arrêter la commande mais j’avoue ne pas pouvoir expliquer pourquoi ça fait ça plus en détail.
[^] # Re: Ce sont eux
Posté par DaVi . Évalué à 1.
Je crois que cela restera l'un des mystères de Linux.
En tout cas , si on me dit que Linux c'est de la me*de; je pourrai répondre que c'est le seul OS qui permet de "leur" parler !
http://github.com/DaudrVignieCharles/
# Shift + Espace
Posté par nigaiden . Évalué à 4.
Tu n'aurais pas une carte du clavier qui génère des espaces insécables ou autre caractère rigolo quand on saisit 'Shift + Espace' ? Je suis à peu près sûr que ton fichier
/tmp/test_bytesn'existe pas car le shell a compriscat /dev/uranom >_/tmp/test_bytes.[^] # Re: Shift + Espace
Posté par freem . Évalué à 2.
dans ce cas, soit le shell n'aurait pas trouvé la commande, soit la commande cat aurait attendu une entrée utilisateur, soit elle aurait indiqué que le fichier fournit n'existe pas.
[^] # Re: Shift + Espace
Posté par wismerhill . Évalué à 2.
Hé non, fais le test, cat ne teste un fichier que quand il a fini de traiter le précédent, et comme avec /dev/urandom il n'aura jamais fini, donc tu n'(arrive pas au message d'erreur sur un deuxième fichier qui n'existerait pas.
Mais ça ne devrait pas être ça le problème (ou alors seulement en partie), car > est un opérateur du shell, donc même si le caractère qui suit n'est pas un espace ce sera quand même interprété comme une redirection (sauf si c'est un caractère spécial qui change le type de redirection), mais pas vers le fichier que tu crois. (et là ça peut faire une erreur directe du shell s'il ne peut pas écrire dedans)
[^] # Re: Shift + Espace
Posté par freem . Évalué à 2.
Justement, je l'ai fait, le test. Enfin, j'ai copié/collé le cat cité plus haut que je suppose avoir un espace insécable.
C'est ainsi que j'ai eu l'un des cas que j'ai décris, mais je reconnais avoir supposé les 2 autres, en fonction de l'implémentation de cat et du shell (qui peut très bien avoir implémenté cat en built-in et dans ce cas, il est délicat de prédire le comportement).
[^] # Re: Shift + Espace
Posté par nigaiden . Évalué à 1.
Il a peut-être entré involontairement quelque chose comme
cat /dev/urandom _> /tmp_test_bytes(où_serait un caractère à la con).catne vérifie pas les fichiers au lancement mais uniquement lorsqu'il doit ouvrir les fichiers (test pour se convaincre:cat - 404notfound.txt).Si l'auteur revient lire ces lignes, j'aimerais qu'il nous donne le résultat de
history|grep urandom|xxd.[^] # Re: Shift + Espace
Posté par freem . Évalué à 2.
Oui, dans ce cas, l'écran laisse l'utilisateur saisir un texte et l'affiche, ce qui est l'un des cas que j'ai décrit.
Quant à l'auteur, je doute qu'il ait encore la commande dans son historique :)
# C'est bôôôô
Posté par NumOpen . Évalué à 4.
Mieux que MATRIX !
# Séquence d'échappement
Posté par BFG . Évalué à 4.
Ce qui cause cet affichage est une séquence d'échappement du terminal.
Les séquences d'échappement sont des séquences d'octets particulières permettant de modifier l'affichage de diverses façons. Parmi les plus courantes, on trouve de quoi changer la couleur de la police, déplacer le curseur texte à une position particulière, ou changer le titre du terminal. Le générateur aléatoire peut tout à fait produire de telle séquences, qui affecteront votre terminal.
La séquence qui a eu cet effet drastique est probablement celle qui change le jeu de caractères.
Vous pouvez tester (attention le terminal deviendra difficile à lire) :
printf "\033(0ceci est un test\n"Pour rétablir le terminal taper ceci (à l'aveugle) :
printf "\033(B\n", ou taper la commandereset.[^] # Re: Séquence d'échappement
Posté par Marotte ⛧ . Évalué à 2.
Merci c’est très clairement expliqué.
Cela dit ce que je n’arrive toujours pas à comprendre (et qui n’est visiblement pas un bug) c’est pourquoi un bout de /dev/urandom atterri dans l’entrée standard du terminal alors qu’il y a une redirection.
Ce que je crois comprendre c’est que lorsque que l’utilisateur envoie son BREAK (avec Ctrl+c) c’est d’abord la redirection qui se termine, puis le cat, d’où du data, qui comme tu l’expliques peut contenir par hasard des séquences d’échappement, qui arrive dans l’entrée du terminal entre temps ?
[^] # Re: Séquence d'échappement
Posté par BFG . Évalué à 2.
Cela ne se passe pas ainsi.
Quand on a tapé une commande sans redirection et qu'on presse entrée, le shell effectue d'abord un appel système
fork()(man 2 fork), ce qui clone le processus du shell, sa mémoire, ses descripteurs de fichiers (dontstdin,stdoutetstderr) et l'endroit où il en est dans le programme.Ensuite, le shell original se contente d'attendre la fin du nouveau processus.
Pendant ce temps, le sous processus (qui est encore un shell) effectue l'appel système
execve(man 2 execve) qui charge un nouveau programme et remplace tout le processus par ce nouveau programme (en l'occurence, la commande tapée par l'utilisateur). Le nouveau programme va alors utiliser les mêmesstdin,stdoutetstderrque son parent, à savoir, le terminal.Une fois l'appel
execvefait, le sous-processus n'exécute plus du tout un shell et ses entrées sorties ne sont donc plus contrôlées par le shell. À moins quecatlui-même ne décide de changer ses entrées/sorties standard, il écrira vers le terminal.Si la commande tapée contenait une redirection, la séquence est à peu près la même, à part qu'après le
fork(), le sous-processus (qui est encore un shell), va rediriger sa propre sortie standard (et seulement la sienne) vers un fichier avant de faire leexecve: le sous-processus du shell va ouvrir le fichier demandé (et quitter si le fichier ne peut être ouvert, sans faireexecve), puis faire la redirection avec l'appeldup2(man 2 dup2). Ainsi, quand il appelleraexecve,catécrira vers le fichier quand il écrira vers sa sortie standard, au lieu du terminal.Aussi, comme pour le cas précédent, après
execve, le shell n'aura plus la main sur le processuscat.En bref, il n'est pas possible pour le shell de "stopper la redirection" d'un autre processus.
Je pense que nous n'avons pas la commande exacte tapée par DaVi, comme le dit le fil précédent.
[^] # Re: Séquence d'échappement
Posté par DaVi . Évalué à 1. Dernière modification le 15 octobre 2016 à 21:59.
La commande est exacte… C'est bien ça que je ne parviens pas à comprendre. C'est la deuxième fois que j'ai des bugs avec un simple cat /dev/urandom + redirection. Le premier bug avait gelé mon PC me forçant à faire un redémarrage brutal, redémarrage qui ne s'est jamais terminé, même le mode emergency ne fonctionnait plus. Je n'ai effectivement aucune explication logique à ces comportements.
En tout cas, merci pour l’explication qui est claire et intéressante.
http://github.com/DaudrVignieCharles/
[^] # Re: Séquence d'échappement
Posté par DaVi . Évalué à 1.
Précision, cat n'est pas un builtin de mon shell, c'est le bon vieux cat de Stallman et Granlund… donc WTF ?
http://github.com/DaudrVignieCharles/
[^] # Re: Séquence d'échappement
Posté par DaVi . Évalué à 1.
Il me semble que ce soit en effet l'explication la plus crédible, j'ai en effet déjà mis la me*de en testant des séquences ANSI.
http://github.com/DaudrVignieCharles/
[^] # Re: Séquence d'échappement
Posté par MicP . Évalué à 1.
Dans ces cas là, il y a la commande
resetSuivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.