Terminal-Eingabeaufforderung wird nicht korrekt umbrochen


171

Ich habe ein Problem, bei dem das Terminal, wenn ich sehr lange Befehle in Bash eingebe, nicht das wiedergibt, was ich richtig eingebe. Ich würde das erwarten, wenn ich einen Befehl wie den folgenden hätte:

username@someserver ~/somepath $ ssh -i /path/to/private/key
myusername@something.someserver.com

Der Befehl sollte in zwei Zeilen gerendert werden. Stattdessen wird es oft herumlaufen und anfangen, über meine Eingabeaufforderung zu schreiben, in etwa wie folgt:

myreallylongusername@something.somelongserver.comh -i /path/to/private/key

Wenn ich mich entscheide, ein Argument zu ändern, kann ich nicht sagen, wo der Cursor angezeigt wird, manchmal in der Mitte der Eingabeaufforderung, aber normalerweise in der Zeile über der Eingabe.

Zusätzlichen Spaß macht es, wenn ich Upzu einem vorherigen Befehl komme. Ich habe dies sowohl im Gnome-Terminal als auch im Terminator und auf i3 und Cinnamon ausprobiert. Jemand schlug vor, es sei meine Aufforderung. Hier also:

\[\033[01;32m\]\u:\[\033[01;34m\] \W\033[01;34m \$\[\033[00m\]

Ctrll,, resetund clearalle tun, was sie sagen, aber wenn ich den Befehl wieder eingebe oder Updas Gleiche passiert.

Ich habe es überprüft und es checkwinsizeist in Bash aktiviert. Dies passiert bei 80x24 und anderen Fenstergrößen.

Ist das nur etwas, womit ich leben lerne? Gibt es ein Stück Magie, das ich wissen sollte? Ich habe mich entschlossen, nur eine kurze Eingabeaufforderung zu verwenden, aber das behebt das Problem nicht.


1
Die Verwendung des Befehls env -i bash --norcbehebt das Problem. Die $ COLUMNS und $ LINES stimmen überein. Bedeutet das, dass mit meiner .bashrc etwas Komisches passiert?
Muricula

Also habe ich meine .bashrc-Datei auskommentiert und meine Eingabeaufforderung als problematischen Teil herausgestellt, insbesondere die Farbsyntax. Was ist los mit der PS1 oben?
Muricula

1
\[\033[01;32m\]\u: \[\033[01;34m\]\W \[\033[01;34m\] \$ \[\033[0m\]scheint die Verrücktheit im Verhalten zu vermeiden - aber weiß nicht, ob es Ihre ursprüngliche Aufforderung vollständig respektiert ...

1
Verwenden tput smam
Sie

Antworten:


189

Nicht druckbare Sequenzen sollten in \[und eingeschlossen sein\] . Wenn du auf deine PS1 schaust , hat sie eine nicht geschlossene Sequenz \W. Der zweite Eintrag ist jedoch redundant und wiederholt die vorherige Anweisung "1; 34" .

\[\033[01;32m\]\u:\[\033[01;34m\] \W\033[01;34m \$\[\033[00m\]
                  |_____________|               |_|
                         |                       |
                         +--- Let this apply to this as well.

Als solches sollte dies die beabsichtigte Färbung haben:

\[\033[1;32m\]\u:\[\033[1;34m\] \W \$\[\033[0m\]
                               |_____|
                                  |
                                  +---- Bold blue.

Unter Beibehaltung des "Originals" sollte dies auch funktionieren:

\[\033[1;32m\]\u:\[\033[1;34m\] \W\[\033[1;34m\] \$\[\033[0m\]
                                  |_|         |_|
                                   |           |
                                   +-----------+-- Enclose in \[ \]

Bearbeiten:

Der Grund für das Verhalten liegt in bashder Annahme, dass die Eingabeaufforderung länger ist als sie tatsächlich ist. Als einfaches Beispiel, wenn man verwendet:

PS1="\033[0;34m$"
       1 2345678

Es wird angenommen, dass die Eingabeaufforderung aus 8 Zeichen und nicht aus 1 besteht. Wenn das Terminalfenster 20 Spalten umfasst, wird nach Eingabe von 12 Zeichen angenommen, dass es 20 Zeichen enthält, und es wird umbrochen. Dies zeigt sich auch, wenn man dann versucht, Backspace oder Ctrl+u. Es stoppt bei Spalte 9.

Es wird jedoch auch keine neue Zeile gestartet, es sei denn, eine Zeile befindet sich in der letzten Spalte. Infolgedessen wird die erste Zeile überschrieben.

Wenn Sie die Eingabe fortsetzen, sollte die Zeile nach 32 Zeichen in die nächste Zeile umgebrochen werden.


Wenn Sie - oder jemand - eine Erklärung dafür haben, was genau in der ursprünglichen Sequenz dazu geführt hat, dass sich die Zeile wiederholt, wäre ich daran interessiert, das zu wissen. Auch +1, wie Sie dies visuell gezeigt haben.

1
@ illuminÉ: Habe nicht die Quelle angeschaut, sondern ein Update mit einem Hinweis zum Verhalten aus der Beobachtung hinzugefügt.
Runium

Für den Fall, dass Sie auf Probleme stoßen
divinedragon

Das ist erstaunlich, danke @Runium - würde es Ihnen etwas ausmachen, mitzuteilen, woher Sie das wissen? Ich würde gerne eine Dokumentation dazu finden.
Nycynik

2
@nycynik: Beobachtung. Ich denke, die nächstliegende Dokumentation ist der Quellcode ...
Runium

83

Dies hängt hauptsächlich mit der Größe des Fensters zusammen, von dem das Terminal annimmt, dass es nicht mit Ihrer tatsächlichen Fenstergröße übereinstimmt. Wenn Sie Bash verwenden, können Sie dies versuchen.

$ shopt checkwinsize

Wenn Sie nicht bekommen

checkwinsize    on

Dann aktivieren Sie es mit

$ shopt -s checkwinsize

Versuchen Sie dann einfach, einen anderen Befehl (wie ls) auszuführen oder die Fenstergröße einmal zu ändern. Das oben Genannte funktioniert bei mir jedes Mal.

Für Redhat Systeme Insbesondere wird das Problem oft durch Fehlkonfiguration ~/.bashrcnicht zu nennen /etc/bashrc. Normalerweise werden Bash-Ladevorgänge ~/.bashrcaufgerufen /etc/bashrc, die standardmäßig enthalten sind shopt -s checkwinsize.


Hatte das gleiche Problem mit OS X, anscheinend, wenn Sie "login" aufrufen, um Ihr Terminal zu starten, wird bash auf eine Weise gestartet, die / etc / bashrc lautet, aber wenn Sie direkt bash aufrufen, funktioniert ~ / .bashrc nicht Quellensachen standardmäßig, so dass Sie den ungeraden Wrapping-Effekt erhalten. Vielen Dank!
Rogerdpack

Das hat auch bei mir funktioniert. Auf diesem bestimmten Server waren die Farben nicht aktiviert und der Aufruf war korrekt /etc/bashrc. Alles andere war in Ordnung. Es stellte sich heraus, dass dies die Ursache für die Umbruchprobleme ist.
Dhaupin


Sieht nach einer guten Lösung aus. Aber es funktioniert nicht in meiner SSH-Sitzung. Nicht sicher warum. Ich habe den Befehl shopt -s checkwinsizein der SSH-Sitzung ausgeführt. Aber die Verpackung bleibt bestehen.
Qiang Xu

Dies war genau mein Problem - ein Benutzer .bashrc rief nicht / etc / bashrc auf und machte so ein Chaos.
Sobrique

9

Wie bereits in anderen Antworten erwähnt, sollten nicht druckbare Sequenzen \e[0;30mmit eingeschlossen werden \[...\].

Zusätzlich (und was ich noch nicht erwähnt sehe) scheint es, dass \r\nes außerhalb von liegen sollte, \[...\]wenn Sie eine mehrzeilige Eingabeaufforderung haben. Ich brauchte ein bisschen Versuch und Irrtum, um das endlich herauszufinden.


8

Ich habe einmal irgendwo gelesen (ich weiß nicht mehr wo), dass ich dieses Problem mit \001und \002anstelle von \[und \]lösen kann. Es hat für mich getan.

Übrigens muss die Definition von PS1 nicht hässlich aussehen.

green="\001$(tput setaf 2)\002"
blue="\001$(tput setaf 4)\002"
dim="\001$(tput dim)\002"
reset="\001$(tput sgr0)\002"

PS1="$dim[\t] " # [hh:mm:ss]
PS1+="$green\u@\h" # user@host
PS1+="$blue\w\$$reset " # workingdir$

export PS1
unset green blue dim reset

2
Meine PS1 ruft einen Befehl auf, der die Sequenzen druckt, die das OP-Problem verursachen. Nur diese Lösung behebt das Problem für mich.
RickMeasham

6

Das klingt wie ein Problem mit Ihrer COLUMNS& LINESEinstellung der Umgebungsvariablen. Wenn Sie die Größe des Fensters ändern, werden sie normalerweise automatisch von gnome-terminal festgelegt (ich glaube). Sie können die manuelle Festlegung erzwingen, indem Sie den Befehl ausgeben resize.

Beispiel

Wenn ich mein Gnome-Terminal auf 79x17 verkleinere, werden meine Variablen folgendermaßen angezeigt:

$ echo $COLUMNS; echo $LINES
79
17

Ich kann es so erzwingen:

$ resize
COLUMNS=79;
LINES=17;
export COLUMNS LINES;

1
Interessant, hilft aber nicht.
Muricula

1
Dies behebt mein Problem, dass Zeilen nicht korrekt umbrochen wurden, nachdem ich den Befehl "screen" ausgeführt habe. Vielen Dank!!
Nukeguy

5

Um ein Umbrechen zu verhindern, können Sie auch die Anzahl der Spalten erhöhen, indem Sie z

stty columns 120

1
keine sehr gute idee, es hat vim brutal durcheinander gebracht
blauhirn

3

Dasselbe Problem kann auch durch die Verwendung von breiten Unicode-Symbolen verursacht werden (z. B. von https://stackoverflow.com/a/34812608/1657819 ). Hier ist das Snippet das Problem verursacht (etwas dagegen die $Greenund $Redrichtig Farbe Saiten entkam):

FancyX='\342\234\227'
Checkmark='\342\234\223'


# Add a bright white exit status for the last command
PS1="$White\$? "
# If it was successful, print a green check mark. Otherwise, print
# a red X.
if [[ $Last_Command == 0 ]]; then
    PS1+="$Green$Checkmark "
else
    PS1+="$Red$FancyX "
fi

Bash kann die Länge nicht korrekt berechnen. Der einfachste Weg ist, 2 von 3 Teilen dieser breiten Symbole zu maskieren.

FancyX='\[\342\234\]\227'
Checkmark='\[\342\234\]\223'

Macht Sinn. Was ich denke ist, dass Bash Zeichen zählt. Da das X ein Zeichen hat, aber als 3 geschrieben ist, muss man 2 davon einschließen, um die Zählung zu korrigieren. @blauhirn Antwort erklärt auch, wie man in einer Funktion mit \001und umgeht \002.
Akostadinov

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.