nano

[flk]

Weil bei mir das editieren mit vi selten ohne fluchen abläuft, wäre ich ganz glücklich, wenn das auch ins BS könnte

[seife]

Aber gerne!

[flk]

cool ... hab aber wieder mal nicht richtig aufgepasst. So ist s wahrscheinlich besser

[bellum]

Hi,
ich habe bei mir ein fast identisches Target drin und nutze nano auch gerne vor allem in der seriellen Konsole mit PuTTY in einem großen Fenster.
Dabei habe ich aber leider den Effekt dass nano nicht den kompletten Bildschirm ausfüllt sondern links oben in der Ecke klebt.
Mit PuTTY per Telnet, skaliert es dagegen sehr schön mit der Fenstergröße.
Hat jemand einen Tipp für mich, was man ändern muss, damit das auch in der seriellen Konsole so ist?

Danke und Gruß
bellum

[flk]

Hi,
den Fall hatte ich bisher nie. Serielle Verbindung baue ich eigentlich nur dann auf, wenn ich muss. Weil ich das mit dem Laptop direkt beim Receiver mache und da meistens am Boden sitze ist mir alles andere zu unbequem . Ich habs aber jetzt mal testweise versucht. Bin davon ausgegangen, dass du putty unter Windows verwendest, unter Linux wär das ja nicht unbedingt nötig. Das wird dir jetzt nicht großartig weiterhelfen, aber bei mir ging das Skalieren von nano auf die volle Fenstergröße out of the box.

edit:
Unter Linux hab ich auch den von dir beschriebenen Effekt, und zwar völlig unabhängig vom verwendeten Terminal Programm. Geht weder mit putty, minicom oder gtkterm im vollen Fenster.

[doc]

Dann schau mal im Source, dies dürfte dann hardcoded sein.
War früher bei minicom genauso.

[bellum]

Bin davon ausgegangen, dass du putty unter Windows verwendest

Ja Windows 7 mit PuTTY 0.62.
Ich habe das gerade noch einmal versucht, ohne Erfolg...
Hast Du vielleicht irgendwelche Einstellungen für die Verbindungen gemacht?
Interessant ist, dass nach dem Beenden von nano z.B. eine Ausgabe von 'ls -la'
lediglich auch links oben in dem Bereich von nano zu sehen ist.

Kannst Du mir zum Gegentest einmal Dein nano Binary hier anhängen?

Danke und Gruß bellum

[flk]

Hi,

Docs Einwand von wegen hardcoded hat mich jetzt unsicher gemacht. Ich hab nochmal probiert und musste feststellen, dass das gestern falscher Alarm war. Liegt wohl daran, dass Logging in der Konsole aktiviert war und das Log übers ganze Fenster geschrieben worden ist. Nano ist aber auch nur im linken oberen Viertel. Geht also bei mir unter Windows auch nicht anders.

Da hilft mein nano bin leider auch nicht weiter.

[seife]

Die Kernel-Konsole reagiert, wenn ich mich recht erinnere, nicht auf die Steuercodes mit dem ein Programm die Höhe/Breite/Farben etc. abfrägt. Deswegen bleibt dem Programm nichts anderes übrig, als ein Fallback auf den kleinsten gemeinsamen Nenner: 80x25.

Oder sowas in der Art. Ist bei virtuellen Maschinen mit seriellen oder paravirtualisierten Konsolen oft auch so, da kämpfe ich täglich damit

[bellum]

Die Kernel-Konsole reagiert, wenn ich mich recht erinnere, nicht auf die Steuercodes mit dem ein Programm die Höhe/Breite/Farben etc. abfrägt. Deswegen bleibt dem Programm nichts anderes übrig, als ein Fallback auf den kleinsten gemeinsamen Nenner: 80x25.

Oder sowas in der Art. Ist bei virtuellen Maschinen mit seriellen oder paravirtualisierten Konsolen oft auch so, da kämpfe ich täglich damit

Gibt es da eine Lösung/Workaround dafür?
So ist das nämlich doch etwas unschön, vor allem weil alle weiteren Ausgaben dann auch in dem 80x25 Bereich stattfinden...

Gruß bellum

[seife]

telnet, ssh sind doch gute Lösungen?
oder nach dem verwenden eines ncurses-Programms halt "reset" eingeben.

Man könnte natürlich den Konsolentreiber im Kernel erweitern, dass es dieselben Protokolle versteht wie die erweiterten terminals, aber irgendwie kenne ich niemand, der freiwillig am Konsolencode rumpatchen will.