Pourquoi cette invite bash conserve-t-elle parfois une partie des commandes précédentes lors du défilement de l'historique?

Mon invite bash, que j'avoue avoir volé à quelques endroits et bricolé, ajoutera parfois une partie des commandes précédentes à sa longueur lors du défilement de l'historique bash avec des flèches haut / bas.

Par exemple, si mes commandes précédentes étaient:

ls
cd /home/caleb
vim .bashrc

Lorsque j'étais à mon invite et que j'ai fait défiler deux fois vers le haut, cela pourrait ressembler à:

$ vim .bcd / home / caleb

Où les cinq premiers caractères sont restés de la dernière commande.

Quelqu'un a-t-il une idée pourquoi cela se produit et comment cela peut être arrêté?

Mon invite est définie avec ce code (trop long pour l'inclure ici): https://gist.github.com/1679352

Quelque part, votre invite est fubar. Ce qui se passe généralement, c'est que votre shell pense qu'il sort des codes de termes non imprimables et s'attend à ce qu'il prenne de la place. Le meilleur conseil que je puisse vous donner est d'ajouter systématiquement (ou de supprimer) votre invite jusqu'à ce que ce comportement s'arrête pour isoler le code à l'origine de ce problème.

Les codes de couleur doivent être placés entre crochets. Les crochets informent bash que le texte joint ne doit pas être imprimé

en s'appuyant sur l'exemple de @ Phreditor, cela montre que toute mise en forme effectuée après la nouvelle ligne entraînera le problème d'origine:

export PS1="\n\n\[\033[01;33m[\w]\033[00m\n\033[0;90m\$ "

encapsuler le code de format dans [] garantit que les comportements ennuyeux ne se produisent jamais:

export PS1="\n\[\[\033[01;33m\][\w]\[\033[00m\]\n\[\033[0;90m\]\$ "

La documentation: http://tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html

Étant donné que le formatage PS1 rend la valeur si longue et difficile à lire, je mets les codes de format dans des variables:

BYELLOW='\[\033[01;33m\]'
IBLACK='\[\033[0;90m\]'
PS_CLEAR='\[\033[0m\]'
export PS1="\n${BYELLOW}[\w]${PS_CLEAR}\n${IBLACK}\$ "

J'ai eu le même problème et c'était lié aux définitions des couleurs.

Dans mon cas, j'ai une invite sur plusieurs lignes (donne plus d'espace pour la commande actuelle quelle que soit la longueur de chemin affichée par l'invite).

Mauvaise version:

export PS1="\n\n\[\033[01;33m[\w]\n\033[00m\$ "

Bonne version:

export PS1="\n\n\[\033[01;33m[\w]\033[00m\n\$ "

\033[00mtermine la couleur. Si c'est après la nouvelle ligne ( \n), cela empêche un nouveau tracé correct dans le terminal, pour remplacer les commandes précédentes par la couleur d'arrière-plan. Le déplacer derrière la nouvelle ligne a résolu le problème.

(en utilisant Terminal sous Mac OS 10.8)

En fait, je pense que cela a à voir avec un délimiteur de «caractère non imprimable» manquant. J'ai eu exactement le même problème, mais le déplacer avant la nouvelle ligne (\ n) ne l'a pas résolu. Au lieu de cela, j'ai correctement entouré tous les caractères non imprimables (ici, les commandes de coloration) avec '\ [' et '\]'.

Mauvais (fonctionne, mais présente le problème de purge d'historique décrit ci-dessus):

PS1="\e[32m\u\e[35m@\e[32m\h \e[33m\w\e[36m\n\$\e[0m"

Bon (entouré de toutes les commandes de couleur par '\ [' et '\]' - n'affiche pas l'historique des commandes écrasées):

PS1="\[\e[32m\]\u\[\e[35m\]@\[\e[32m\]\h \[\e[33m\]\w\[\e[36m\]\n\$\[\e[0m\]"

i.e. "\e[...m" --becomes--> "\[\e[...m\]"

Et si vous mettez ceci dans quelque chose comme SecureCRT pour envoyer automatiquement lors de la connexion à un système, vous devrez peut-être tout double échapper (mettre des doubles barres obliques inverses partout) si le système de connexion automatique consomme la première barre oblique inverse elle-même pour déterminer le caractère à envoyer :

PS1="\\[\\e[32m\\]\\u\\[\\e[35m\\]@\\[\\e[32m\\]\\h \\[\\e[33m\\]\\w\\[\\e[36m\\]\\n\\$\\[\\e[0m\\]"

i.e. "\..." --becomes--> "\\..."

(Ceci est certainement vrai pour SecureCRT et peut être vrai pour d'autres, tels que PuTTY ou TeraTerm - tests requis de votre part.)