Hallo,
ich beschäftige mich gerade mit VT220 & Co. Beim Line Feed/New Line Mode
bin ich etwas verwirrt. Auszug der Beschreibung:
1
Line feed/new line mode selects the control character(s) transmitted to the application by the Return and Enter keys. [...]
2
3
Line feed/new line also selects the action taken by the terminal when receiving line feed (LF), form feed (FF), or vertical tab (VT) codes. These three codes are always processed identically. [...]
4
5
Set - Causes a received LF, FF, or VT code to move the cursor to the first column of the next line. Return sends both a CR and a LF code.
6
Reset - Causes a received LF, FF, or VT code to move the cursor to the next line in the current column. Return sends a CR code only.
Wenn also der Mode gesetzt ist, setzt ein LineFeed den Cursor an die
erste Position der nächsten Zeile, gesendet wird aber ein CarriageReturn
+ LineFeed. Und bei rückgesetztem Mode benötigt das Terminal ein
CarriageReturn + LineFeed, sendet aber nur ein CarriageReturn.
Also irgendwie gegensätzlich, wie begründet sich das? Hängt das mit den
unterschiedlichen NewLine-Definitionen der Betriebssysteme zusammen?
Soweit ich weiß verwendet Unix/Linux LF und DOS/Windows CR+LF.
Wenn OS-NewLine = LF und der LNM gesetzt ist, dann setzt das Terminal
den Cursor in die erste Position der nächsten Zeile. Zurück kommt CR+LF,
wobei das CR wirkungslos ist, weil dieses den Cursor nur an die erste
Position setzt, aber in der gleichen Zeile bleibt. Das enthaltene LF
macht das gleiche plus den Zeilensprung.
OS-NewLine = CR + LF und LNM nicht gesetzt funktioniert zum Terminal,
aber da nur CR zurückgesendet wird gibt's keinen LF. Also stimmt die
Theorie bzgl. OS wohl eher nicht.
Kann jemand Licht ins Dunkel bringen?
Grüße
set funktioniert bei DOS, CP/M, MP/M, concurrentDOS. Reset funktioniert
bei Unixen. Dazu gabs noch Kommandos, um an eine bestimmte Position am
Bildschirm zu springen. Aber das ist zu lange her..
Hallo Helge,
> set funktioniert bei DOS, CP/M, MP/M, concurrentDOS. Reset funktioniert> bei Unixen.
Das wäre bei DOS dann OS-Newline = CR+LF und ein LF setzt an die erste
Position der nächsten Zeile. Ein empfangenes CR bleibt wirkungslos.
Zurückgesendet wird CR+LF, das passt.
Linux, OS-NewLine = LF: ein empfangenes LF setzt den Cursor nur in die
nächste Zeile. Und gesendet wird nur ein CR. Wie funktioniert das dann,
die Kombi beisst sich ja dann auch? Dann müsste vom Host ein zu
sendendes LF in ein CR+LF gewandelt werden und beim Empfang eines CR ein
CR+LF generiert werden. Oder verstehe ich da was falsch?
Grüße
Ich sage mal so: Das hat schon in den 90er Jahren für massive Verwirrung
und Inkompatibilitäten gesorgt. Manche Dinge wurden in der IT so
gründlich versaut, dass sie uns für immer Ärger bereiten.
Selbst die vorliegende Forensoftware (in der mehr als 10 Jahre
Detailverbesserungen stecken), zeigt Umbrüche in Textdateien manchmal
"unerwartet anders" an.
Ralf schrieb:> Wenn also der Mode gesetzt ist, setzt ein LineFeed den Cursor an> die erste Position der nächsten Zeile, gesendet wird aber ein> CarriageReturn + LineFeed. Und bei rückgesetztem Mode benötigt> das Terminal ein CarriageReturn + LineFeed, sendet aber nur ein> CarriageReturn.> Also irgendwie gegensätzlich, wie begründet sich das?
Betrachte das mal anders herum: normal und natürlicherweise hat jedes
Steuerzeichen genau eine Funktion. Wenn man diesen speziellen Mode
einschaltet, bekommen zwei Steuerzeichen eine zusätzliche Funktion, und
zwar abhängig von der Datenrichtung. Dass der Mode zwei Sachen
beeinflusst, die garnichts miteinander zu tun haben, fördert natürlich
die Verwirrung. Auch "man console_codes" (Linux Console) verwirrt eher
noch mehr:
"Automatically follow echo of LF, VT or FF with CR."
In Richtung Terminal sehe ich noch einen kleinen Nutzen, man spart pro
Zeile ein Zeichen. In der anderen Richtung wird es doch nur
komplizierter. Da wartet ein Programm darauf, dass der User ENTER
drückt. Welchen Vorteil hat da das zusätzliche Zeichen? Der Terminal
Emulator urxvt implementiert auch nur eine Richtung¹.
Das Gute ist: dieser Mode wurde schon 1986 offiziell wieder abgeschafft.
Die 5. Ausgabe der ECMA-048 schreibt²:
1
F.5 Eliminated modes
2
F.5.1 Editing Boundary Mode (EBM)
3
The mode EDITING BOUNDARY MODE (EBM) the use of which was
4
already declared deprecated in the fourth Edition of this
5
Standard has now been removed.
6
F.5.2 LINE FEED/NEW LINE MODE (LF/NL)
7
The mode LINE FEED/NEW LINE MODE (LF/NL) the use of which
8
was already declared deprecated in the fourth Edition of
Hallo Stefan & Bauform,
ja, das ganze ist doch ziemlich verwirrend. Die ECMAs hab ich zusammen
mit den jeweiligen VTxxx Handbüchern, die sind meine Basis. Dass der LNM
zum Schluss abgeschafft wurde hab ich ehrlicherweise in der 5.Edition
der ECMA-48 nicht gesehen. Einzug ins VT220 & Co hat das wohl nicht
gefunden. So langsam versteh ich aber auch, warum nicht jede Sequenz bei
jedem Terminalprogramm funktioniert...
Ich schätze ich werde dann den LNM explizit zurück setzen, wie es DEC
empfiehlt. Sicherheitshalber den Mode auch abfragen und ggf. den
Benutzer initial auffordern die Return-Taste zu drücken, um zu sehen was
zurückkommt und entsprechend meine eigene NewLine-Definition anpassen.
Danke euch.
Grüße
Thread beobachten
Seitenaufteilung abschalten