Comment obtenir de longues lignes de commande pour envelopper la ligne suivante?

92

Ce que j'ai remarqué depuis longtemps dans Ubuntu est frustrant: lorsque je tape une commande sur la ligne de commande qui devient plus longue que la largeur du terminal, au lieu de la faire retourne à 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 réelle, 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. Qu'est-ce que je tape est la suivante:

echo abcdefghijklmnopqrstuvwxyz

Mais à quoi ressemble mon terminal avant d’appuyer sur la touche:

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

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 ma commande sur 2 lignes différentes. Mais tant que je me souviens avoir utilisé Ubuntu, mes longues commandes n'occupent qu'une seule ligne.

Cela se produit également lorsque je reviens aux commandes précédentes de l’historique (j’appuie sur Echap, puis sur 'K' pour revenir aux commandes précédentes) - lorsque je parviens à une commande précédente plus longue que la largeur du terminal, ligne de commande est déchiré et je ne peux pas dire où je suis dans la commande.

Le seul travail 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. Je viens de taper mon nom d’hôte pour me connecter, et j’ai toujours le problème. Je dois apporter des modifications à la 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 jettent en quelque sorte. Je suis maintenant avec les variables standard bash pour mon $ PS1.

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

... End Edit ...

    
posée BrianH 01.02.2011 - 21:17
la source

6 réponses

119

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 le moment d’emballer 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 n'a que 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 10 colonnes de l'invite car il ignore les octets entre les% d'échappement spéciaux \[ et \] :

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

Par contre, utilisez tput pour générer les échappements 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 lien , ainsi que lien pour plus sur tput .

    
réponse donnée geirha 02.02.2011 - 09:00
la source
56

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

Assurez-vous que vous avez \[ dans votre citation PS1 précédant votre jeu de couleurs

Par exemple:

PS1='\[\e[0;32m\[email protected]\w/:\[\e[m '
    
réponse donnée user10070 02.02.2011 - 08:06
la source
9

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

Ajoutez la ligne suivante dans votre fichier .bashrc :

COLUMNS=250

Ensuite, tapez source ~/.bashrc pour obtenir l’effet désiré.

    
réponse donnée Deboshree 17.04.2012 - 12:58
la source
5

J'avais le même problème avec une invite de couleur personnalisée, même si je contenais des codes de couleur dans les délimiteurs \[ et \] . Il s'avère 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.

    
réponse donnée reentim 06.05.2012 - 06:20
la source
1

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

stty columns 1000

Par exemple,

stty columns 1000
PS1='\[\e[0;32m\[email protected]\w/:[\e[m '

cependant, cela affecte d’autres commandes Unix comme ls et man.

    
réponse donnée Gennady 12.02.2013 - 16:27
la source
0

J'ai eu ce problème lorsqu’il était connecté à tmux. Le problème était que j'avais une session ipython en arrière-plan ( ctrl + z ) et que cela brisait en quelque sorte le retour à la ligne. 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.

    
réponse donnée Ciprian Tomoiagă 07.04.2017 - 22:39
la source

Lire d'autres questions sur les étiquettes