126 votes

Comment faire pour que les longues lignes de commande passent à la ligne suivante ?

J'ai remarqué quelque chose de frustrant dans Ubuntu depuis longtemps : lorsque je tape une commande sur la ligne de commande qui devient plus longue (plus large) que la largeur du terminal, au lieu de passer à une nouvelle ligne, il revient à la 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, il écrase le texte qui était affiché).

C'est difficile à expliquer sans le voir, mais supposons que mon terminal ait une largeur de 20 caractères (le mien fait plutôt 120 caractères - mais pour l'exemple), et que je veuille faire écho à l'alphabet anglais. Ce que je tape est ceci :

echo abcdefghijklmnopqrstuvwxyz

Mais ce à quoi ressemble mon terminal avant que j'appuie sur la touche :

pqrstuvwxyzghijklmno

Quand j'appuie sur la touche entrée, il y a un écho

abcdefghijklmnopqrstuvwxyz

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

Voici ce qui devrait se passer si je tape cette commande dans un terminal de 20 caractères seulement :

echo abcdefghijklmno
pqrstuvwxyz

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

set -o vi

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

Dans tous les autres environnements dans lesquels j'ai travaillé, si je tape une longue ligne de commande, il ajoute une nouvelle ligne sous la ligne sur laquelle je travaille lorsque ma commande devient plus longue que la largeur du terminal et lorsque je continue à taper, je peux voir ma commande sur 2 lignes différentes. Mais aussi longtemps que je me souvienne d'avoir utilisé Ubuntu, mes longues commandes n'occupaient qu'une seule ligne.

Cela se produit également lorsque je reviens à des commandes précédentes dans l'historique (j'appuie sur Esc, puis sur 'K' pour revenir à des commandes précédentes) - lorsque j'arrive à une commande précédente qui était plus longue que la largeur du terminal, la ligne de commande est déformée et je ne peux pas dire où je me trouve dans la commande.

La seule solution que j'ai trouvée pour voir l'intégralité de la longue commande est d'appuyer sur "Esc-V", ce qui ouvre la commande en cours dans un éditeur VI.

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

J'ai téléchargé une nouvelle copie de Putty et je n'ai apporté aucun changement à la configuration - j'ai juste tapé le nom de mon hôte pour me connecter, et j'ai toujours le problème, donc je ne pense pas qu'il s'agisse d'un problème avec Putty (à moins que je doive apporter des changements à la configuration).

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

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 l'ont en quelque sorte perturbé. Je m'en tiens maintenant aux variables standard de bash pour mon $PS1.

Merci à @ændrük pour l'astuce sur le .bashrc !

...Fin de l'édition...

164voto

Steve Karg Points 11

Assurez-vous que tous les octets non imprimables de votre PS1 sont contenus dans le fichier \[ \] . Sinon, bash les comptera dans la longueur de l'invite. Il utilise la longueur de l'invite pour déterminer le moment où il faut enrouler la ligne.

Par exemple, ici, bash considère que l'invite fait 19 colonnes de large, alors que l'invite affichée par le terminal ne fait que 10 colonnes de large ( My prompt écrit en cyan, et > écrit dans la couleur par défaut) :

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

alors qu'ici, l'invite ne compte que pour une largeur de 10 colonnes car elle ignore les octets entre les caractères spéciaux. \[ y \] s'échappe :

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

Toutefois, pour une bonne pratique, utilisez tput pour générer les échappatoires 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\]>'

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

60voto

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

Assurez-vous juste que vous avez \[ à l'intérieur de votre PS1 devis précédant votre jeu de couleurs

Par exemple :

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

15voto

user55336 Points 3

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

Ajoutez la ligne suivante dans votre .bashrc archivo:

COLUMNS=250

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

5voto

reentim Points 51

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

5voto

Gennady Points 69

Une chose simple à faire serait d'ajouter la ligne suivante avant de définir le 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.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X