Question Comment puis-je obtenir de longues lignes de commande pour envelopper la ligne suivante?


Quelque chose que j'ai remarqué dans Ubuntu pendant une longue période et qui a été frustrant pour moi, c'est lorsque je tape une commande sur la ligne de commande qui devient plus longue que la largeur du terminal, au lieu de revenir à une nouvelle ligne. colonne 1 sur la même ligne et commence à écraser le début de ma ligne de commande. (Il n’écrase pas réellement la commande, mais visuellement, elle écrase le texte qui s’affiche).

C'est difficile à expliquer sans le voir, mais disons que mon terminal était large de 20 caractères (le mien ressemble plus à 120 caractères - mais à titre d'exemple) et je veux faire écho à l'alphabet anglais. Ce que je tape est la suivante:

echo abcdefghijklmnopqrstuvwxyz

Mais à quoi ressemble mon terminal avant que je frappe la clé est:

pqrstuvwxyzghijklmno

Quand j'appuie sur Entrée, ça fait écho

abcdefghijklmnopqrstuvwxyz

donc je sais que la commande a été reçue correctement. Il a juste emballé ma frappe après le "o" et a commencé sur la même ligne.

Ce à quoi je m'attendais, si je tapais cette commande sur un terminal de 20 caractères seulement, serait le suivant:

echo abcdefghijklmno
pqrstuvwxyz

Contexte: J'utilise bash comme shell et j'ai cette ligne dans mon ~ / .bashrc:

set -o vi

pour pouvoir naviguer dans la ligne de commande avec les commandes VI. J'utilise actuellement le serveur Ubuntu 10.10 et je me connecte au serveur avec Putty.

Dans tout autre environnement dans lequel j'ai travaillé, si je tape une longue ligne de commande, il ajoutera une nouvelle ligne sous la ligne sur laquelle je travaille lorsque ma commande est plus longue que la largeur du terminal et que je continue à taper. 2 lignes différentes. Mais aussi longtemps que je me souviens d'avoir utilisé Ubuntu, mes longues commandes n'occupent qu'une ligne.

Cela se produit également lorsque je reviens aux commandes précédentes de l’historique (j’appuie sur Échap, puis sur «K» pour revenir aux commandes précédentes). mutilé et je ne peux pas dire où je suis dans la commande.

Le seul contournement que j'ai trouvé pour voir toute la longue commande est d'appuyer sur "Esc-V", ce qui ouvre la commande en cours dans un éditeur de VI.

Je ne pense pas avoir quelque chose de bizarre dans mon fichier .bashrc. J'ai commenté la ligne "set -o vi", et j'ai toujours eu le problème.

J'ai téléchargé une nouvelle copie de Putty et je n'ai apporté aucune modification à la configuration - j'ai simplement tapé mon nom d'hôte pour me connecter et j'ai toujours le problème, alors je ne pense pas que ce soit le cas avec Putty faire des changements de configuration)

Quelqu'un d'autre a-t-il eu ce problème, et peut-on penser à la façon de le réparer?

modifier

C'était mon fichier .bashrc. J'ai copié le même profil d'une machine à l'autre, et j'ai utilisé des caractères spéciaux dans mon $ PS1 qui le rejette. Je reste maintenant avec les variables standard bash pour mon $ PS1.

Merci à @ ændrük pour le conseil sur le .bashrc!

... End Edit ...


93
2018-02-01 20:17


origine


Juste pour être sûr que le problème ne soit pas causé par votre fichier .bashrc, je vous recommande de le remplacer temporairement par une copie de /etc/skel/.bashrc. N'oubliez pas que vous devrez vous reconnecter pour que les modifications prennent effet et veillez à conserver une sauvegarde de votre propre fichier .bashrc. - ændrük
Quelle application de terminal utilisez-vous? Le comportement que vous décrivez n'est pas habituel, certainement pas un défaut. - João Pinto
Dans les shells dans lesquels j'ai travaillé (et dans Cisco CLI), vous pouvez également taper Ctrl-L pour réafficher la ligne que vous tapez, même si elle est hors écran. Dans votre situation, cela peut encore produire la sortie cassée dont vous parlez, mais je serais curieux. - belacqua
N'hésitez pas à créer une "réponse" expliquant la solution et à la marquer comme acceptée. Cela peut sembler un peu idiot, mais avoir une bonne réponse permet de garder le site organisé et de guider plus efficacement les personnes qui ont des problèmes similaires dans le futur. - ændrük
Selon cette réponse sur serverfault, utilisation tput smam - Samveen


Réponses:


Assurez-vous que tous les octets non imprimables de votre PS1 sont contenus dans \[ \]. Sinon, bash les comptera dans la longueur de l'invite. Il utilise la longueur de l'invite pour déterminer à quel moment envelopper la ligne.

Par exemple, ici bash compte l'invite en tant que 19 colonnes de large, tandis que l'invite affichée par le terminal est seulement 10 colonnes de large (My prompt écrit en cyan, et > écrit en couleur par défaut):

PS1='\e[36mMy prompt\e[0m>'         # bash count: 19, actual: 10

alors qu'ici il ne compte que l'invite de 10 colonnes de large parce qu'il ignore les octets entre les spéciaux \[ et \] s'échappe:

PS1='\[\e[36m\]My prompt\[\e[0m\]>' # bash count: 10, actual: 10

Pour de bonnes pratiques cependant, utilisez tput pour générer les sorties du terminal plutôt que de les coder en dur:

cyan=$(tput setaf 6) # \e[36m
reset=$(tput sgr0)   # \e[0m
PS1='\[$cyan\]My prompt\[$reset\]>'

Voir http://mywiki.wooledge.org/BashFAQ/053, et aussi http://wiki.bash-hackers.org/scripting/terminalcodes pour plus sur tput.


119
2018-02-02 08:00



C'est une excellente explication du problème que la réponse acceptée ne fournit pas - Jamie Cook
Dans la dernière ligne de code PS1='...' : pourquoi ne pas guillemets simples $cyan et $reset de substitution? - andrybak
@andrybak, ils empêchent $cyan et $resetd'être substitué, mais PS1 est évalué à chaque fois que l'invite est imprimée. Vous pouvez voir cela en essayant PS1='$var> ' et ensuite donner var différentes valeurs et voir comment l’invite change. Alors essaye PS1="$var> "  et notez que l'invite reste statique; $var s'est élargi pendant la mission, pas à chaque fois PS1 est évalué. - geirha
Ceci est incroyable. Merci beaucoup d'avoir posté ceci! Cela rend les passages entre crochets beaucoup plus faciles et plus lisibles. - phyatt
Comment je fais ce travail PS1=${PS1}"\e]2;$@\a" . j'ai essayé PS1=${PS1}"\[\e]2;\]$@\[\a\]" - Ramana Reddy


Je suppose que vous avez configuré votre PS1 avec des couleurs, non?

Assurez-vous juste d'avoir \[ à l'intérieur de votre PS1 citation précédant votre jeu de couleurs

Par exemple:

PS1='\[\e[0;32m\u@\w/:\[\e[m '

56
2018-02-02 07:06



Mon PS1 était export PS1='^[[96m'$(hostname)'<^[[92m${PWD}^[[96m>^[[97m ' - Je l'utilise depuis longtemps - c'est compatible avec KSH ... - BrianH
Sensationnel. J'utilise les invites de terminal depuis toujours et je n'ai jamais eu ce problème auparavant. Je n'aurais jamais compris ça. Merci. - bchurchill
Utiliser \ [en utilisant des guillemets simples produit une barre oblique involontaire. aussi, il devrait être utilisé] à la fin des caractères magiques, comme noté dans la réponse la mieux votée - igorsantos07
-1 ne fonctionne pas. Tu dois emballage la section non imprimable avec \[ au début et \] à la fin. - wjandrea
@ igorsantos07 La double barre oblique inverse dans \\[ était une faute de frappe provoquée par un montage. Je l'ai corrigé - wjandrea


J'ai eu un problème similaire et j'ai finalement trouvé une solution simple.

Ajouter la ligne suivante dans votre .bashrc fichier:

COLUMNS=250

Puis tapez source ~/.bashrc pour obtenir l'effet désiré.


10
2018-04-17 10:58



Dans certains cas, tels que les subdivisions de terminateur étroites, le problème ne réside pas dans les caractères de couleur promt mais dans une valeur COLUMNS incorrecte. Cette réponse m'a sorti d'un trou très ennuyeux! - Carles Sala
La déconnexion est inutile. Faire source .bashrc. Votre invite se mettra à jour immédiatement - Sergiy Kolodyazhnyy
J'ai trouvé cela depuis que je n'avais pas Shopt setwinsize mis pour ma bash, donc il ne mettait pas à jour les colonnes à droite, voir unix.stackexchange.com/a/167911/8337 - rogerdpack
J'ai fait export COLUMNS=250 suivi par export TERM=xterm et c'était heureux. - Philip Kearns


J'ai eu le même problème avec une invite de couleur personnalisée, même si j'ai contenu des codes de couleur dans \[ et \] délimiteurs. Il se trouve que bash a des problèmes pour faire écho aux couleurs de l'intérieur d'une fonction. J'ai fini par utiliser des variables pour mon invite, et bien que mon fichier .bashrc soit un peu moins élégant, tout fonctionne parfaitement maintenant.


5
2018-05-06 04:20



Si quelqu'un lit encore ceci, il est effectivement possible d'échapper aux couleurs d'une fonction. Voir cette réponse sur la question liée. - wjandrea


Une chose simple à faire serait d'ajouter la ligne suivante avant de configurer la PS1:

stty columns 1000

Par exemple,

stty columns 1000
PS1='\[\e[0;32m\u@\w/:[\e[m '

Cependant, cela affecte d'autres commandes Unix comme ls et man.


2
2018-02-12 15:27



Cela fonctionne dans OSX. - raskhadafi
Cela affecte également vim mal. S'il vous plaît ne pas utiliser cela. - justhalf


J'ai eu ce problème lorsque connecté en tmux. Le problème était que j'avais un ipython session en arrière-plan (ctrl + z) et qui en quelque sorte ont cassé l’emballage. Dès que je l'ai résilié (fg, ctrl+d+d) mon terminal a commencé à fonctionner correctement

Vérifiez donc toutes les invites interactives arrêtées.


0
2018-04-07 20:39