bash / console: Keine neue Zeile bei langen Befehlen

Errorsmith

Kompiliertier
Hi

Ich hab das Problem, das ich bei längeren Befehlen auf der Konsole keine neue Zeile mehr bekomme.
Wenn ich also zum Beispiel das da eingebe:
Code:
[root@rechner: /usr/local/etc ]# cd /usr/ports/sysutils/smartmontools && make config-recursive && make install && cd /usr/ports/ports-mgmt/portmaster && make install && make clean
bricht er zwar am Ende der Zeile um, bleibt aber in der selben Zeile und "überschreibt" die bereits gemachten Eingaben. Desweiteren bricht er spätestens bei 97 Zeichen um, unabhängig davon, ob das Terminal mehr Zeichenbreite hat.

Kann mir jemand sagen woran das liegt?

Ich verwende:
10.0-BETA4 FreeBSD 10.0-BETA4
GNU bash, version 4.2.45(0)

Grüße,
errorsmith
 
Im Prinzip richtig, aber es "ging ja sonst immer".
Aus irgendeinem Grund weicht die Konsole vom gewohnten Verhalten ab und ich wüßte gern wieso. Und wie ich das gewohnte Verhalten wieder herstellen kann. Es ist nämlich etwas hinderlich wenn ich einen Befehl mit "Cursor up" wiederholen oder bearbeiten will. Dann setzt der die lange Zeile in die Zeile "über dem Prompt" und überschreibt dort alles. Es betrifft auch die Ausgabe von Befehlen wenn sie lang genug ist:
Code:
echo "seeeeeeeeeeeeeeeeeeeeeeeeeeeeeehr laaaaaaaaaaaaaaaaaaangeeeeeeeeeeeeeeeeeeee Teeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeext"
wird ebenfalls auf die beschriebene Weise in der gleichen Zeile umgebrochen. Das Problem tritt übrigens unabhängig davon auf ob ich mit SSH reingehe oder mich direkt auf der Maschine anmelde.

Grüße,
errorsmith
 
Hast du ein upgrade gemacht? Ich hatte das Problem auch, als ich st selber gebacken und installiert habe und danach ein Systemupgrade gemacht habe. Bei mir war die Lösung, die termcap aus dem sourcetree wieder herzustellen und die Definitionen für st erneut hinzuzufügen.
 
Ich habe ein Upgrade gemacht: Der Rechner ist "frisch" installiert (Installation vom Memstick, Upgrade über die Sourcen + Welt/Kernel neu bauen)
Woran sehe ich den dass es mir die termcap zerlegt hat? Ich hab da mal reingeschaut, das ist alles recht kryptisch für mich...

Grüße,
errorsmith
 
Bei mir hat sich das so geäußert, dass beim Starten der Shell eine Fehlermeldung ausgegeben wurde, von wegen „Console type unknown“ oder so ähnlich.
Könnte sein, dass die Meldung in einer langen MotD untergeht oder so.
 
Hi,
ich habe das gleiche oder zumindest ein aehnliches Verhalten in der bash beobachten koennen. Das Problem scheint zu sein, dass die bash unter bestimmten Umstaenden nicht mitbekommt wenn sich die Groesse des Terminalfensters, in dem die bash grade laeuft, aendert, i.e. SIGWINCH nicht erhaelt oder verarbeitet. Ich kann das auf meinem Rechner z.B. wie folgt reproduzieren (alles in einem xterm mit bash, # = Kommentar):
Code:
$ vim
# Terminal in Y-Richtung (positiv) vergroessern
:q # vim schliessen
$ langes_kommando
langes_kommando (in Zeile n) wird nun nach so vielen Zeichen 'umgebrochen', wie das Terminalfenster vor dem Vergroessern breit war. Nach dem Zeilenumbruch geht es in der selben Zeile (also wieder in Zeile n und nicht etwa in der naechsten Zeile n+1) weiter wobei als erstes der Prompt ueberschrieben wird.

Abhilfe kann man z.B. dadurch schaffen, in dem man der bash explizit SIGWINCH sendet:
Code:
$ kill -s WINCH $$
Das ist zwar nervig, aber lange nicht so nervig wie eine bash, die denkt in einem kleineren Terminalfenster zu laufen. Vielleicht hilft das ja auch bei dir?

Viele Gruesse,
teuk
 
Hi

Das hat leider nicht geholfen. Ich habe aber herausgefunden, das es nur passiert wenn ich mit "su -l" zu Benutzer 'root' wechsele, oder wenn ich mich (an der Maschine direkt) als root anmelde. Bleibe ich als normaler User eingeloggt passiert es nicht. Nun bin ich endültig verwirrt!?

errorsmith
 
Ich habe aber herausgefunden, das es nur passiert wenn ich mit "su -l" zu Benutzer 'root' wechsele, oder wenn ich mich (an der Maschine direkt) als root anmelde.
Benutzen Normaluser und Root wirklich dieselbe Shell?
Wenn ja, dann liegt es wohl an den Umgebungsvariablen. Einfach mal für beide mit "env" ausgeben und vergleichen.
Interessant wäre auch der Fall, wenn Du "su" ohne "-l" benutzt; dann wird das Environment nicht zurückgesetzt, und vermutlich hat dann der Root auch kein Problem.
Nebenbei: Welche FreeBSD-Version hast Du denn vorher benutzt, als Du das Problem noch nicht hattest?
 
Zurück
Oben