Touche home agissant bizarrement en bash (tty et X) sur les longues chaînes d'entrée


11

Lorsque je frappe Homesi mon entrée actuelle est suffisamment courte (disons <36 caractères), cela fonctionne bien. Cependant, lorsque j'ai tapé une commande plus longue et que je veux revenir au début, il semble que cela fasse son travail, mais la commande ne s'affiche plus correctement. Il semble que je ne sois pas au début, mais à environ 10 caractères de moins. Bien que si je tape "aveuglément", cela fonctionne très bien, mais cela ressemble à un gâchis total, comme si l'entrée entière était décalée vers la droite, mais pas redessinée. Donc je tape dessus, mais "en fait" non, car l'endroit que je "gomme" est "en fait" 10 caractères à droite. Par conséquent, si j'essaie d'effacer la commande, les 10 premiers caractères sont toujours affichés, mais si je la frappe, Entercela affiche simplement une autre invite comme si l'entrée précédente était vide.

Je sais que ce n'est pas la meilleure explication jamais, mais le fait est que bash le reconnaît et essaie de faire la bonne chose, mais échoue souvent.

Je reproduis cela à la fois en tty et dans un terminal dans une session X. Quand je tape Ctrl+ Vet puis Homeje vois différentes séquences ( ^[OHen X, ^[[1~en tty), mais les deux semblent être dans mon /etc/inputrc:

# do not bell on tab-completion
#set bell-style none

set meta-flag on
set input-meta on
set convert-meta off
set output-meta on

$if mode=emacs

# for linux console and RH/Debian xterm
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[7~": beginning-of-line
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word

# for rxvt
"\e[8~": end-of-line

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line

# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line
$endif

echo $TERMmontre linuxen tty et xtermen session X.

Ses

GNU bash, version 4.2.24 (2) -release (i686-pc-linux-gnu)

Quelqu'un a des indices à ce sujet?


1
Quelle est la longueur de votre invite? La saisie d'une ligne de commande d'environ 36 caractères remplit-elle une ligne de votre terminal et provoque-t-elle ainsi un défilement latéral? Cela se produit-il toujours si vous utilisez cette invite? PS1='$ '
Mikel

@Mikel Je ne sais pas ce que vous avez en tête, mais vous êtes probablement sur la bonne voie. Cela ne semble pas se produire lorsque j'utilise l'invite minimaliste. Celui que j'ai utilisé était un peu modifié par rapport à la valeur par défaut d' un: PS1="\e[0;36m[\u@\h \W]\$ \e[m". Y a-t-il quelque chose qui cloche? Taper 36 caractères ne remplit pas une ligne (de loin). De plus, je n'ai pas de défilement latéral en tty :)
Lev Levitsky

@Mikel J'ai suivi les conseils de jw013 et ajusté l'invite, qui semble le résoudre. Peut-être pourriez-vous expliquer quel était le problème afin que je puisse vous récompenser avec un représentant comme celui qui le comprendra en premier :)
Lev Levitsky

Réponses:


13

Vous devez entourer les parties non imprimables de votre invite (y compris, mais sans s'y limiter, les séquences d'échappement pour changer les couleurs) avec \[et \].

Votre invite d'origine: \e[0;36m[\u@\h \W]\$ \e[m
invite fixe:\[\e[0;36m\][\u@\h \W]\$ \[\e[m\]

Le \[et \]indique bashque tout ce qui se trouve entre les deux ne s'imprime pas réellement à l'écran, c'est-à-dire qu'il n'a aucune longueur. La longueur de l'invite calculée est nécessaire pour savoir où faire écho aux caractères que vous tapez. Laisser de côté \[ \]entraîne bashle calcul d'une longueur d'invite incorrecte, ce qui conduit souvent à un comportement étrange dépendant de la géométrie du terminal en raison de bashl'idée de l'endroit où le curseur ne correspond pas à la réalité.


Merci, cela résout le problème. J'apprécierais cependant quelques explications: quelle était la raison de ce comportement, que font les crochets, etc. Ce serait bien de tout avoir sur une seule page et pourrait aider quelqu'un d'autre à l'avenir.
Lev Levitsky

@LevLevitsky J'ai ajouté une courte explication à la réponse.
jw013

Grand merci! Cela me semble plus logique maintenant.
Lev Levitsky
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.