Welche Art von Terminal soll unterstützt werden, wenn ein Terminal-Emulator implementiert wird?

Geschlossen . Diese Frage ist meinungsbasiert. Antworten werden derzeit nicht akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage, damit sie mit Fakten und Zitaten beantwortet werden kann, indem Sie diesen Beitrag bearbeiten.

Vor 4 Jahren geschlossen.

Verbessern Sie diese Frage

Ich habe gehört, dass VT100 der De-facto-Standard ist. Bedeutet es, dass ich nur VT100 unterstützen kann und mein Terminal dann ohne große Probleme für vorhandene Befehlszeilenanwendungen funktionieren kann? Wenn nicht, wie kann man sicherstellen, dass das Terminal praktisch ist? Gibt es eine Referenz, die helfen kann, dieses Ziel zu erreichen?

Akzeptierte Antwort:

Du bist dabei, Thomas Dickey zu überhitzen.

Ignorieren Sie den Samizdat, der seit Jahren über VT10x-Terminals kursiert. Vieles davon ist falsch. Die DEC VT100, VT101 und VT102 implementierten einen sehr spezifischen Satz von Funktionen, die man beim Lesen ihrer Dokumentation lernen kann.

Das ist nicht was Leute, die fälschlicherweise um die Begriffe vt100 gehen und vt102 eigentlich aber gemeint. Oft sprechen sie von einer Terminalemulation, die eine ganze Menge mehr leistet als das, was ein echter VT10x tat, sowie eine ganze Menge weniger . Ein echter DEC VT102 hatte zum Beispiel einen angeschlossenen seriellen Drucker und Steuersequenzen für den Zugriff darauf. Außerdem nicht haben viele der Steuersequenzen von späteren Terminal-Emulatoren und echten Terminals, die Leute fälschlicherweise „vt102“ zuschreiben. Es hatte zum Beispiel kein Konzept für SGR-Farbänderungen.

Sie haben zwei grundlegende Möglichkeiten:

• Implementieren Sie etwas, das mit einem bestehenden Terminaltyp kompatibel ist, der in den Datenbanken termcap/termininfo definiert ist. Wenn Sie dies tun, müssen Sie es korrekt tun und das gesamte beschriebene Verhalten des vorhandenen Terminaltyps genau kopieren. (Der Terminal-Emulator des Nosh-Toolsets tut dies, indem er unter Linux den linux emuliert Terminaltyp. Es muss den linux kopieren die skurrilen und begrenzten erweiterten Tasten- und Funktionstastencodierungen des Terminaltyps.)
• Implementieren Sie Ihren eigenen Terminaltyp, dessen Verhalten von Ihnen entworfen wird, den Sie dann in die termcap/termininfo-Datenbank aufnehmen müssen. Genau genommen tut dies der Terminalemulator PuTTY. Die korrekte Termininfo-Beschreibung dafür ist putty , putty-256color , oder putty-sco .

Für Ersteres ist es irrelevant, was Standard ist, da Sie das beschriebene Verhalten kopieren müssen, egal wie nicht standardmäßig es sein mag. Suchen Sie für Letzteres nicht nach De-facto-Standards. Sehen Sie sich das tatsächliche an Standards, von denen einige seit 1976 existieren.

• ECMA-48 (erstmals 1976 veröffentlicht und später als ISO/IEC-Standard übernommen, ISO/IEC 6429) beschreibt:
  • C0-Steuercodes,
  • C1-Steuercodes (die wenig bekannt sind, aber einige nützliche Dinge wie das Setzen/Löschen von Tabstopps und den Vorwärts-/Rückwärtsindex behandeln)
  • 7-Bit-Aliase für alle C1-Steuercodes (zum Beispiel ESC [ ist ein 7-Bit-Alias ​​für actual 8-Bit-Steuerzeichen U+009B),
  • von CSI eingeführte Steuersequenzen (für die es im Standard eine allgemeine Syntax gibt, die viele samizdat-geschriebene Steuersequenz-Parser falsch machen),
  • und viele andere Sachen.
• ISO/IEC 2022 beschreibt das Umschalten zwischen 7-Bit-Zeichensätzen. Wenn Sie UTF-8-Fähigkeit von Anfang an implementieren möchten, ignorieren Sie ISO/IEC 2022 am besten vollständig, wie Markus Kuhn und die Erfinder von mosh wird es dir sagen.
• ISO/IEC 8613-6 (veröffentlicht 1989 und überarbeitet 1994) beschreibt Erweiterungen zu ECMA-48 für Farb-SGR-Steuersequenzen, sowohl „indizierte Farbauswahl“ aus einer Palette als auch „direkte Farb“-RGB. (Beide direkte Farbe und indizierte Farbe sind in ISO/IEC 8613-2 definiert. Letzteres kennen Sie wahrscheinlich unter dem Samizdat-Namen „256 Farben“.)

  Wichtiger Hinweis: Fast alle Implementierungen implementieren diesen Standard falsch, weil sie von samizdat aus arbeiteten (oder sich einfach gegenseitig kopierten) und nicht vom eigentlichen Standard. Der Standard sagt in §13.1.8, Doppelpunkte zu verwenden (: , „3/10“) als Unterparameter-Trennzeichen; Fast alle Implementierungen verwenden fälschlicherweise Semikolon (; ) und führt eine Mehrdeutigkeit bei der Analyse ein. Viele Softwareprogramme haben diesen Fehler behoben.

Verwandte:Was zeigt dieser Prozess STAT an?

Weiterführende Literatur

• Steuerfunktionen für codierte Zeichensätze . ECMA-48. 5. Auflage. 1991. ECMA International.
• Informationstechnologie – Open Document Architecture (ODA) und Austauschformat:Dokumentstrukturen . T.412. Internationale Fernmeldeunion.
• Informationstechnologie – Open Document Architecture (ODA) und Austauschformat:Zeicheninhaltsarchitekturen . T.416. Internationale Fernmeldeunion.
• Informationstechnologie – Open Document Architecture (ODA) und Austauschformat:Zeicheninhaltsarchitekturen . ISO/IEC 8613-6:1994. Internationale Organisation für Normung.
• Markus Kühn (2009). „Was sind die Probleme im Zusammenhang mit UTF-8-Terminalemulatoren?“. UTF-8 und Unicode FAQ für Unix/Linux .
• Keith Winstein, Anders Kaseorg, et al. (2012). „ISO 2022 Verriegelung von Fluchtwegen“. Technische Informationen zu Mosh .
• VT420-Programmiergerät-Referenzhandbuch . EK-VT420-RM-002. Februar 1992. Digital.
• Informationen zum VT520/VT525-Videoterminalprogrammierer . EK-VT520-RM. Juli 1994. Digital.
• Thomas E. Dickey (1997). „Was ist ein VT220?“. Häufig gestellte Fragen zu xterm . unsichtbare Insel.