BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6497
|
Hallo zusammen, immer wieder habe ich in letzter Zeit das Problem, dass meine Eingabeaufforderung (bash) seltsame Dinge macht. Ich bin via SSH auf einem Rechner und dann kommt es vor, dass bspw. die Cursorposition verschoben ist. Manchmal verrutscht der Cursor um eine ganze Zeile, manchmal steht er einfach innerhalb der Zeile an der falschen Stelle. Das ist schwierig zu erklären, ich mach hier mal ein Beispiel: # die Nachfolgende Zeile hieß 'curl -R https://URL/v2'. Ich habe sie aus der History geholt, bin mit den Pfeiltasten nach Links und habe das R durch ein I ersetzt:
docker3:~# curl -I https://URL/v2
No command 'Iurl' found, did you mean:
Command 'zurl' from package 'zurl' (universe)
Command 'curl' from package 'curl' (main)
Iurl: command not found
# wie man sieht ist hier was schief gelaufen. Hole ich den letzten Befehl aus der History (via Pfeiltaste aufwärts) sehe ich, was ich eigentlich eingegeben hatte:
docker3:~# Iurl -R https://URL/v2 Das ist echt böse. Hat jemand eine Idee, an was das liegen könnte? (Meine lokale .bashrc ist glaub ziemlich verhunzt, kann es sein, dass die trotz dem Remote-Arbeiten hier rum pfuscht? Hier posten mag ich sie grad nicht ...)
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17622
Wohnort: Berlin
|
Tritt das immer auf? Wenn Programme abstürzen oder man mit Escapesequenzen rumpfuscht oder -spielt tritt das schon mal auf. In denen Fällen hilft ein
Dabei wird der Bildschirm gelöscht, also wichtige Informationen vorher lesen, und während der Eingabe kann die Ausgabe ganz verschwunden sein, also unbeirrt schwarz tippen. Wenn die Einstellungen dauerhaft futsch sind, weil die Konfiguration hin ist, dann ist es schwierig. Sicherheitskopien machen, und alle eigenen Ergänzungen rausschmeißen und mit der iterativen Halbierungsmethode von der Differenz immer die Hälfte der verbliebenen Änderungen wieder reinstellen, und dann entweder vom neuen Rest die Hälfte, wenn es gut lief, oder vom zugefügten die Hälfte wieder rauswerfen, wenn nicht - die ältesten Änderungen zuerst restaurieren. Man kennt das vom Zahlenraten, größer/kleiner wo jemand eine Zahl von 0 bis 1024 gefunden. In 10 Schritten hat man jede Zahl geraten.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17622
Wohnort: Berlin
|
Kleiner Exkurs zur Methode des iterativen Halbierens:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | #!/bin/bash
iterfind () {
ziel=$1
jetzt=$2
step=$3
if (( ziel == jetzt ))
then
echo "gefunden: $ziel"
else if (( ziel > jetzt ))
then
echo "$jetzt (step: $step)"
iterfind $ziel $(( jetzt + step/2 )) $(( step / 2 ))
else
echo "$jetzt (step: $step)"
iterfind $ziel $(( jetzt - step/2 )) $(( step / 2 ))
fi
fi
}
iterfind $1 $2 $3
# Aufruf:
# bash iterfind.sh $((RANDOM%1024)) 512 512
# iterfind 461 512 512
|
in 10 Schritten kann man 2'° Möglichkeiten abklappern, wenn man weiß ob man jeweils drüber oder drunter suchen muss, also 1024. In 20 Schritten findet man aus 1 Million. Jede vierte Suche dauert 10 Schritte, jede 2. neun, ein Viertel der Suchen 8, ein 8tel 7 Schritte und so weiter und mit 1/1024 Wahrscheinlichkeit trifft man auf Anhieb. Exkurs 2: Bei Escapesequenzen berechnet die Shell manchmal falsch, wie breit ein Zeichen in der Ausgabe ist. Sie posiert dann den Cursor falsch, womöglich mitten in der vorigen Zeichenkette, man denkt man habe sich vertippt und versucht zu korrigieren, dabei wäre es richtig blind weiterzutippen. Das ist aber wohl nur eine denkbare Fehlerquelle. Aber prompting ist ein heißer Kandidat für solche Fehler.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Solch ein Phänomen, dass der Cursor sonstwohin verrutscht, kenne ich vor allem nach komplexen Ausgaben, die das Terminal scrollen lassen, und nebenbei dann auch noch ein paar seltsame Dinge tun. Als Mittel dagegen gebe ich erstmal ein oder zwei Mal nur [Enter] ein (einen leeren Befehl sozusagen). Danach habe ich normalerweise wieder einen normalen Prompt. So als erstes Modell könnte man eine Ausgabe mit Steuerzeichen nehmen: (probier es mal !) Ganz wild wird es, wenn Du solche Steuersequenzen in Deinem Prompt verbaut hast. (Schau mal, was in $PS1 und Konsorten bei Dir drin steht !) Vor allem, wenn die [eckige Klammerung] nicht stimmt, dann berücksichtigt er nicht druckbare Zeichen (wie z.B. solche Steuersequenzen) beim einzählen der Cursorposition falsch. Die erste Frage wäre also: setzt er den Cursor immer falsch ? - oder: unter welchen Bedingungen ? Oder passiert da was völlig Zufälliges ? Vielleicht reicht es ja schon, $PS1 auf den Standard-Wert zu setzen. (und: wirkt bei ssh womöglich dann der Prompt des Hosts ?) LG, track
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4694
Wohnort: Berlin
|
Was auch noch sein könnte ist, dass die Gegenseite Dein(e) Terminal(emulation) falsch identifiziert und Steuerzeichenfolgen sendet, die nicht zu Deinem Terminal passen. Was gibt denn wenn Du remote angemeldet bist echo $TERM aus, und passt das zum/zur Terminal(emulation) auf Deiner Seite? Und haben $LINES und $COLUMNS Werte die auch tatsächlich stimmen?
|
BillMaier
Supporter
(Themenstarter)
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6497
|
Danke für Eure Hinweise. Ich habe wie gesagt die lokale .bashrc in Verdacht und werde Eure Ansätze mal durch checken bzw. die lokale bashrc raus werfen. user_unknown schrieb: Tritt das immer auf?
Mittlerweile verhäuft, was ich mir durch zu viele verschiedene Komponenten erklären könnte. Also muss ich es mal durch spielen. Aber jetzt weiß ich zumindest wo ich ansetzen kann. Werde mich dann wieder melden.
|
BillMaier
Supporter
(Themenstarter)
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6497
|
Ich glaub ich habs schon. Ich nehme stark an, dass diese Änderung auf den RemoteHosts das Problem verursacht - oder zumindest stark - verstärkt haben. - PS1='${debian_chroot:+($debian_chroot)}\[\033[0;32m\]$(hostname --fqdn)\[\033[00m\]:\[\033[01;34m\]\w\}[\033[00m\]\$ '
+ PS1='${debian_chroot:+($debian_chroot)}\[\033[0;32m\]$(hostname --fqdn)\[\033[00m\]:\[\033[01;34m\]\w\$\033[00m\] ' track schrieb: Vor allem, wenn die [eckige Klammerung] nicht stimmt, dann berücksichtigt er nicht druckbare Zeichen (wie z.B. solche Steuersequenzen) beim einzählen der Cursorposition falsch.
Guter Punkt. Wer passt auch schon auf, dass zwei Mal [[ und einmal ] vor kommen...
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 13213
|
Manche Programme haben auch ein Problem mit sehr großen Terminals. Wenn ich z.B. ein Terminal maximiere und dann dort vim starte, passieren u.U. auch seltsame Dinge.
|
BillMaier
Supporter
(Themenstarter)
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6497
|
Das widerum hatte ich noch nie. Ich arbeite täglich mit vim in einem maximierten Terminal ☺ // edited: aber ich erinnere mich an ein altes Debian 5, da wollte ich ebenfalls eine Datei mit vim bearbeiten - und die Eingabe war komplett kaputt, der Cursor meist 1 oder 2 Zeichen neben dem eigentlichen etc. . Das ist wie wenn plötzlich die Dinge nach oben fallen statt nach unten ...
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 13213
|
BillMaier schrieb: Das widerum hatte ich noch nie. Ich arbeite täglich mit vim in einem maximierten Terminal ☺
Au Mann! Ich habe Deine Bemerkung mal zum Anlass genommen, in meine ~/.vimrc zu schauen. Und da fand sich folgendes: set co=135 lines=45 Das hatte ich mal dort aufgenommen, damit gvim nicht mit so einem Winzfenster startet. Jetzt habe ich es in eine ~/.gvimrc gepackt. Danke für den Stupser!
|