Forum général.général J'adore Debian et autres ; bug rigolo

Posté par  . Licence CC By‑SA.
Étiquettes :
0
6
août
2016

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
Et voici ce qu'est devenue mon terminal :

Le bug en question

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  . É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  . É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  . É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  . É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  . É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  . É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_bytes n'existe pas car le shell a compris cat /dev/uranom >_/tmp/test_bytes.

    • [^] # Re: Shift + Espace

      Posté par  . É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  . É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  . É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  . Évalué à 1.

        Il a peut-être entré involontairement quelque chose comme cat /dev/urandom _> /tmp_test_bytes (où _ serait un caractère à la con). cat ne 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  . É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  . Évalué à 4.

    Mieux que MATRIX !

  • # Séquence d'échappement

    Posté par  . É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 commande reset.

    • [^] # Re: Séquence d'échappement

      Posté par  . É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  . Évalué à 2.

        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

        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 (dont stdin, stdout et stderr) 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êmes stdin, stdout et stderr que son parent, à savoir, le terminal.
        Une fois l'appel execve fait, 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 que cat lui-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 le execve : le sous-processus du shell va ouvrir le fichier demandé (et quitter si le fichier ne peut être ouvert, sans faire execve), puis faire la redirection avec l'appel dup2 (man 2 dup2). Ainsi, quand il appellera execve, 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 processus cat.

        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  . É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  . É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  . É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/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.