Forum Linux.général [FIXED] Un vieux bug avec bash pour les longues commandes.

Posté par  .
Étiquettes : aucune
2
8
sept.
2012

Bonjour à tous,

Depuis deux ou trois ans, je rencontre régulièrement un bug avec bash, j'ai jamais fais de rapport de bug parce que je n'ai jamais réussi à le décrire, et parce qu'il est tellement énorme et courant que j'étais sûr que c'était vain, probablement bêtement.

Souvent (plusieurs fois par semaine) alors que j'édite une longue commande, le terminal ne revient pas à la ligne, je commence à taper une ligne, puis il continue en écrasant le début de la ligne, sans en commencer de nouvelle (mais si je lance la commande c'est bon, c'est juste l'affichage qui merde). Je suppose que ce bug est dans bash, parce que relancer bash dans le même terminal corrige le problème.

Ça ressemble à ça (avec le prompt en gras, ou ce qu'il en reste) :

la lignemputer 23:50 ~ $ voici une commande super longue qui écrase le début de

Cette chaine fait exactement 79 caractères, ça doit pas être un hasard.

C'est un bug que j'ai rencontré avec toutes les distributions, sans rien avoir de folichon dans mon bashrc (quelques alias et un prompt en couleur), sur divers terminaux virtuels, est-ce qu'il est connu ? Le rencontrez vous ?

  • # À mon avis, c'est la couleur du prompt

    Posté par  (site web personnel) . Évalué à 2.

    Ça pue le caractère d'échappement qui manque, ou un truc comme ça.
    Tu as essayé sans la couleur ? Tu pourrais nous mettre le code de ton prompt en couleur, histoire qu'on le regarde ?

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: À mon avis, c'est la couleur du prompt

      Posté par  . Évalué à 1. Dernière modification le 09 septembre 2012 à 01:39. 

      PS1='\[\033[0;36m\]\u\[\033[1;35m\]@\h\[\033[00m\] \[\033[0;35m\]\A\[\033[00m\]\[\033[0;33m\] \w\[\033[00m\] \$ '

      Je l'ai fait a mes tout début, j'avais galéré un moment. Je vais essayer le prompt par défaut un moment, je verrais bien.

      Please do not feed the trolls

      • [^] # Re: À mon avis, c'est la couleur du prompt

        Posté par  (site web personnel) . Évalué à 1.

        Bah écoute, moi je n'ai pas de bug :

        luc@eddard 08:50 ~ $tesuirte rauite srauiet srauit esuira tesiruaetuisrnetuisr tsruiea tsruiet sreaui trsnauit srenuiat ersuiat ersuaiet sruiaet rsiaun tersuni tsrui tsruin teisrun tuisrnt esruint sruina teiusn teiuras teuisan teuisrn teuiasr tiesrnt sriu tsriunt sriaut sruint suirnt sruat rseiut rsu tisrun tsuir t

        Je sais pas, je sèche, je ne vois pas d'erreur dans ton PS1.

        Pour info, chez moi (et je n'ai pas de bashrc):

        $ bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: À mon avis, c'est la couleur du prompt

      Posté par  . Évalué à 1.

      Ça me l'a refait avec le prompt par défaut, la couleur n'y est pour rien. C'est lors d'une complétion automatique que le problème a semblé s'être déclaré.

      Please do not feed the trolls

  • # resize

    Posté par  . Évalué à 7.

    Je ne comprend pas bien l'ensemble des détails techniques qui mènent à ce problème, mais c'est lié à une différence entre la taille de la fenêtre qui influe sur le nombre de caractère par ligne, et le nombre de caractères configurés pour le tty.

    pour régler ça :

    $ # la méthode simple, c'est d'utiliser resize
$ eval $(resize)

$ # on peut aussi utiliser stty en lui donnant le nombre de colonnes. Je ne sais pas trop comment ça se récupère, mais au pire, il y a toujours la bonne vielle méthode dichotomique :-)
$ stty cols <nb cols>

    • [^] # Re: resize

      Posté par  . Évalué à 3. Dernière modification le 09 septembre 2012 à 18:50.

      Ça ressemble exactement à ça :

      https://blogs.oracle.com/dp/entry/why_bash_doesn_t_work

      Il donne une méthode pour le reproduire ! \o/
      - ouvrir une fenêtre terminale pas maximisée
      - lancer vi
      - maximiser la taille fenêtre
      - quitter vi
      - écrire un truc très long et admirer le résultat

      $ bash --version
GNU bash, version 4.2.37(1)-release (x86_64-redhat-linux-gnu)

      Je vais faire un rapport de bug du coup.

      ajout : Tout excité j'ai lu en diagonale, il donne même une solution. Je vais tout de même faire un rapport de bug dans la distro.

      Please do not feed the trolls

  • # meme personne ou pas ?

    Posté par  (site web personnel) . Évalué à 1.

    http://forum.pcinpact.com/topic/164138-probleme-de-promt-command/

    • [^] # Re: meme personne ou pas ?

      Posté par  . Évalué à 1.

      Non ce n'est pas moi, mais mon problème ressemble exactement à ça, à part que ça ce fait tout seul, aléatoirement et que j'ai rien fais de spécial, et qu'il ne revient pas du tout à la ligne.

      Please do not feed the trolls

  • # Terminaux virtuels ....

    Posté par  (site web personnel) . Évalué à -1.

    tu écris que ton pb est sur des terminaux virtuels, est ce que la virtualisation est assurée par XEN ?

    J'ai rencontré exactement le même problème sur des terminaux pour accéder à des machines virtuelles XEN, et le bug était dans mon cas dans la partie virtualisation et pas dans bash….

Suivre le flux des commentaires

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