Diskussion:ANSI-Escapesequenz

Warum gerade die ANSI-Sequenzen?

Leider interpretiert jedes Terminal leicht unterschiedliche Escape-Sequenzen. Es gab zwar den Versuch der ANSI, diese zu normieren, aber welches Text-Terminal oder welcher Terminal-Emulator interpretiert wirkliche die ANSI-Norm komplett? Soweit ich weiß, kochen weiterhin alle (VT100, Linux-Textkonsole, BSD-Textkonsole, xterm, Putty, Gnome Terminal und wie sie alle heißen) ihr eigenes Süppchen. Viele mögen einen "ANSI-kompatiblen" Modus anbieten oder streben eine mehr oder weniger weit gehende Kompatibilität zur ANSI-Norm an, aber … wer erfüllt sie wirklich zu 100%?

Ich wäre dafür, lieber einen allgemeineren Artikel "Terminal-Escapesequenz" (oder mit einem anderen, besseren Titel) anzulegen, dann wäre er auch zweifesllos relevant. :-)

--RokerHRO (Diskussion) 21:59, 28. Mär. 2016 (CEST)

Also erstens danke für's lesen.

Und zweitens: en:ANSI escape codes sind deswegen relevant, weil diese oft benutzt wurden und werden. Der Artikel ist ja noch nicht fertig, da noch konkrete Beispiele fehlen. Ich bin aber noch nicht so weit – ist also Work In Progress sozusagen…

„ANSI-Escapesequenzen“ ist der Terminus, der ganz oft Verwendung findet und vermutlich sogar zum De-facto-Standard für Steuersequenzen wurde, auch wenn die meisten Implementierungen (VT100, ANSI.SYS etc…) diese nicht vollständig bzw. mit eigenen proprietären Erweiterungen umgesetzt haben. Es gibt daher keine 100%ige „ANSI X3.64“-Implementierung, aber es gibt ganz ganz viele, die sich daran anlehnen.

Die Relevanz ergibt sich aus den unzählichen ANSI-Art-Werken, die über die Startzeiten und Untermenüs von Bulletin-Board-Systemen (BBS) verteilt wurden. Und über ANSI-Bomben. Und über die Demo-Szene, die ANSI-Art immer noch verwendet. Und über die Szene der Release Groups, die auch noch ab und an ANSI-Art nutzen.

Mit der großen Verbreitung von ANSI.SYS in MS-DOS wurden ANSI-Escapesequenzen (bzw. alle Steuersequenzen, nicht bloß die mit ESC eingeleiteten) in allerlei Bereichen und Genres genutzt. Wenn man sich die Quellen ansieht, dann sollte das klar werden – auch, wenn dies vielleicht nur eine Niesche betroffen hat, so ist es eine große Niesche. Der Artikel über Großrechner betrifft ja auch nur eine Niesche – nämlich die Leute, die darauf gearbeitet haben. Relevant ist beides.

Wenn du dir also den englischen Artikel ansiehst, dann kannst du dir vielleicht vorstellen, dass da noch etwas kommt. Namlich: wie ist so eine Steuersequenz grundsätzlich aufgebaut? Und: was sind exemplarisch die wichtigsten? (oder: eine komplette Liste… wäre aber vielleicht doch zu viel) Und ein oder zwei kleine Beispiele. (Wie beim Regulären Ausdruck.)

Anders ausgedrückt: Im Artikel Steuerzeichen finden sich keine Steuersequenzen. Im Artikel Escape-Sequenzen finden sich nicht alle ANSI-Steuersequenzen, sondern nur speziell Steuersequenzen auf Basis von ESC, allerdings nur kurz beschrieben und somit ohne jegliche Details. Einige ANSI-Steuersequenzen basieren jedoch nicht auf ESC.

Dieser Artikel könnte also auch „ANSI-Steuersequenzen“ oder bloß „Steuersequenzen“ heißen. Durchgetzt hat sich aber in jeglicher mir bekannter Dokumentation der Begriff „ANSI-Escapesequenz“, auch wenn die eigentliche Sequenz dann gar nicht auf ESC beruht. Der Fall liegt da vermutlich ziemlich ähnlich wie ANSI-Art, das eigentlich nach ANSI.SYS benannt ist.

Zur Unterscheidung: Escape-Sequenzen sind alle Escapesequenzen und damit auch jene in z.B. Unicode oder gänzlich anderen Standards. ANSI-Escapesequenzen betreffen hingegen im Speziellen vor allem die CSI-Sequenzen, die mithilfe von ESC [ erstellt werden (können), obwohl sie ursprünglich nicht im C0-Bereich sondern in C1-Bereich definiert wurden, aber zum Großteil eben über den C0-ASCII-Bereich als Escapesequenz abgehandelt werden.

Aber, wenn ich das falsch sehen sollte… Ich bin für weitere Meinungen offen…

‣Andreas•⚖ 23:34, 28. Mär. 2016 (CEST)

Anmerkungen / Verbesserungs-Ideen

Was mir beim Lesen des Artikels so aufgefallen ist:

1. Die Tabelle der 8-Bit-"Steuerzeichen" ist inkonsistent:
   1. Die Doppelspalte "C0-Position" ist überflüssig und enthält nur einen Eintrag, der zudem keine C0-Position beinhaltet
   2. Die Spalte "Funktion" sollte die Funktion nach ANSI-Norm beinhalten. Dass manche Terminalemulatoren da eigen Süppchen kochen, kann in einer Anmerkung/Fußnote oder dergleichen erwähnt werden.
   3. Was ist der Unterschied zwischen "Startzeichen einer Steuersequenz" und "Einleitung einer Steuersequenz"?
   4. "Index" ist veraltet / gestrichen worden. Gilt das auch für "Reverse Index"?
2. Was hat der Abschnitt "Unicode" mit "ANSI-Escapesequenzen" zu tun? In Unicode sind keine Escapesequenzen enthalten.
3. Wie wäre es mit ein paar Beispielen von häufig benutzten Esacapesequenzen, etwa zum Leeren des Bildschirms, zum Setzen von Farben, zum Positionieren des Cursors usw.?
4. Viele Sondertasten erzeugen ebenfalls eine Escape-Sequenz, allerdings vom Terminal zum Programm (z.B. F1 → "ESC O P" im xterm, aber "ESC [ [ A" in der Linux-Textconsole). Diese sollten ebenfalls erwähnt werden, finde ich. Dann kann man auch besser erklären, was bei "ANSI-Bomben" genau passiert, auch da wieder mit einem kleinen Beispiel.

--RokerHRO (Diskussion) 13:12, 4. Apr. 2016 (CEST)

Ausgezeichnet! Danke für's Lesen!

1. Ich bin dran, den Artikel noch zu verbessern. Ich mache jetzt ersmal die Tabelle fertig. Die Escapesequenzen, die die C1-Steuerzeichen abbilden, sind eigentlich ja auch das, was man unter „ANSI-Escapesequenzen“ versteht.
2. Danach plane ich noch, ein paar Beispiele für die erweiterte Ausgabe aufzuführen. Auch Beispiele für das Umprogrammieren von Tasten oder das automatische Eingeben von Tasten (funktioniert ja ähnlich wie ein Makro) plane ich derzeit.
3. Ob ich eine ANSI-Bombe wirklich als Beispiel haben möchte? Ich glaube, da sollte erklärender Text reichen.
4. Was mir noch am Herzen liegt, ist die Unterscheidung verschiedener proprietärer Implementierungen. Ich hatte irgendwo eine Quelle, die besagt, dass es eine Schnittmenge gibt, die von so gut wie allen ANSI-Implementierungen unterstützt wird. Und diese ist sozusagen der De-facto-ANSI-Escapesequenzen-Standard.
5. Auch ein ANSI.SYS-Beispiel überlege ich derzeit, aber vielleicht sollte das dann in den speziellen Aritkel ANSI.SYS, den ich auch noch irgendwann vor habe zu schreiben.

Nochmals danke!

‣Andreas•⚖ 17:03, 4. Apr. 2016 (CEST)

Antworten zu deinen konkreten Fragen:

• ad 1.3. Unterschied zwischen "Startzeichen einer Steuersequenz" und "Einleitung einer Steuersequenz"
  das Startzeichen ist ein Steuerzeichen, die Einleitung ist die Aktion, die von einem Steuerzeichen, das eine Steuersequenz einleitet, ausgeht.
• ad 2. Unicode
  Ich finde schon, dass Unicode erwähnt werden muss. 1. weil die ASCII- und ANSI-Zeichen ALLE (also auch die Steuerzeichen) in Unicode übernommen wurden, und 2. weil diese Steuerzeichen bei Unicode keine Funktion haben. Allerdings gibt es neue Unicode-Zeichen, die diese Funktion übernehmen, z.B. ein geschütztes Leerzeichen oder ein geschützter Bindestrich.
• ad 4. Was die Escapesequenzen der Sondertasten in xterm etc. betrifft, so bin ich mir nicht sicher, in wie weit das etwas mit den ANSI-Escapesequenzen zu tun hat. Wenn man über „ANSI-Escapesequenzen“ liest oder spricht, dann geht es immer um den umgekehrten Fall, nämlich dass ein „ANSI-Script“ oder der Benutzer aktiv etwas über ANSI-Steuerzeichen/-Steuersequenzen bewerkstelligt. Bei den Escape-Codes in einer Konsole wird hingegen einfach eine Taste in einen solchen umgewandelt. Da ist die Richtung umgekehrt.

‣Andreas•⚖ 13:42, 5. Apr. 2016 (CEST)

Nachtrag ad.4: eine gute Quelle: Terminal Function Key Escape Codes. ‣Andreas•⚖ 22:39, 10. Apr. 2016 (CEST)

Der Artikel ist noch nicht fertig, aber vielleicht ein guter Anfang. (POV)

Was ich noch gerne erledigen würde:

1. Die Beschreibung der C1-Steuerzeichen in den Artikel Steuerzeichen#C1 verschieben. Erledigt. ‣Andreas•⚖ 12:22, 10. Apr. 2016 (CEST)
2. Einheitliche Schreibweise überall (auch in den anderen Artikeln). Ich würde hier die Intel-Schreibweise bevorzugen, also z.B. CSI „9Bh 155 233o“, was „hex dez okt“ entspricht. Wenn man nämlich „0x9B“ für die Hexadezimalzahl verwendet, wie soll man dann die Oktalzahl schreiben? 0233? oder /233? Die Intel-Schreibweise ist 11h für hexadezimal, 21o für oktal und ohne Suffix 17 für dezimal. Damit könnte man das alles in eine Spalte schreiben, was die Formatierung erleichtern würde. Aber das ist erstmal nur eine Idee. Nicht mehr notwendig. ‣Andreas•⚖ 12:22, 10. Apr. 2016 (CEST)
3. Eine Referenz aller Funktionen, die mit CSI möglich sind. Siehe #Umfang. ‣Andreas•⚖ 22:35, 10. Apr. 2016 (CEST)
4. Beispiele für die Verwendung von ANSI-Steuersequenzen. Adhoc fällt mir da ein: ANSI-Art, ANSI-Spiele oder -Programme, ANSI-Bomben, Terminalfunktionen wie das definieren eines Prompt, aber auch die Zuweisung von Tasten(kombinationen) und Shortcuts (wie es auch DOSKEY.EXE ohne ANSI.SYS gemacht hat – vielleicht kennt das noch wer? vergleichbar auch mit einem alias unter einer Unix-Shell), und zuguterletzt (besser wäre, damit zu beginnen) die Konfiguration und Steuerung eines VT52- und VT100-kompatiblen Terminals bzw. dessen Terminalemulation.
5. Weblinks zur VT100-Dokumentation und zu PC-ANSI-Anleitungen und Beispielseiten.
6. Alles noch einmal korrekturlesen.

Wie siehst du das?

‣Andreas•⚖ 13:42, 5. Apr. 2016 (CEST)

Umfang

Welchen Umfang erwarten wir hier im Artikel?

Ich habe mir das mal für CSI, Escapesequenz ESC [ angesehen. Ein Beispiel findet sich in der Linux man-page console_codes(4): die ECMA-48 SGR sequence mit ESC [ <parameter(s)> m oder die ECMA-48 Status Report Commands mit ESC [ <parameter(s)> n.

Der ECMA-48-Standard für CSI ist jedoch weit umfangreicher:

      @   ICH       Insert the indicated # of blank characters.
      A   CUU       Move cursor up the indicated # of rows.
      B   CUD       Move cursor down the indicated # of rows.
      C   CUF       Move cursor right the indicated # of columns.
      D   CUB       Move cursor left the indicated # of columns.
      E   CNL       Move cursor down the indicated # of rows, to column 1.
      F   CPL       Move cursor up the indicated # of rows, to column 1.
      G   CHA       Move cursor to indicated column in current row.
      H   CUP       Move cursor to the indicated row, column (origin at 1,1).
      J   ED        Erase display (default: from cursor to end of display).
                    ESC [ 1 J: erase from start to cursor.
                    ESC [ 2 J: erase whole display.
                    ESC [ 3 J: erase whole display including scroll-back
                               buffer (since Linux 3.0).
      K   EL        Erase line (default: from cursor to end of line).
                    ESC [ 1 K: erase from start of line to cursor.
                    ESC [ 2 K: erase whole line.
      L   IL        Insert the indicated # of blank lines.
      M   DL        Delete the indicated # of lines.
      P   DCH       Delete the indicated # of characters on current line.
      X   ECH       Erase the indicated # of characters on current line.
      a   HPR       Move cursor right the indicated # of columns.
      c   DA        Answer ESC [ ? 6 c: "I am a VT102".
      d   VPA       Move cursor to the indicated row, current column.
      e   VPR       Move cursor down the indicated # of rows.
      f   HVP       Move cursor to the indicated row, column.
      g   TBC       Without parameter: clear tab stop at current position.
                    ESC [ 3 g: delete all tab stops.
      h   SM        Set Mode (see below).
      l   RM        Reset Mode (see below).
      m   SGR       Set attributes (see below).
      n   DSR       Status report (see below).
      q   DECLL     Set keyboard LEDs.
                    ESC [ 0 q: clear all LEDs
                    ESC [ 1 q: set Scroll Lock LED
                    ESC [ 2 q: set Num Lock LED
                    ESC [ 3 q: set Caps Lock LED
      r   DECSTBM   Set scrolling region; parameters are top and bottom row.
      s   ?         Save cursor location.
      u   ?         Restore cursor location.
      `   HPA       Move cursor to indicated column in current row.

Soll das alles im Dateil in den Artikel?

‣Andreas•⚖ 15:51, 10. Apr. 2016 (CEST)

Ich würde 3 bis 4 Beispiele im Artikel erwähnen. z.B.: Cursor positionieren, Bildschirm löschen, Attribute/Farben setzen und vielleicht noch "ESC c", als etwas Exotischeres. Das reicht, um das Grundprinzip und die Möglichkeiten zu kapieren. Der Rest sollte ausgelagert werden, etwa nach "Liste der ANSI-Escapesequenzen" oder sowas. Dort müssen die Sachen dann aber natürlich auf deutsch erklärt werden, sonst hat diese Liste ja keinen Mehrwert gegenüber der engl. Originaldoku, die man natürlich hier als Quellennachweis angeben muss. Ach ja, und in den Erklärungen hätte ich dann auch gerne den Unterschied zwischen z.B. "ESC A" und "ESC F" erklärt, denn der geht aus der jezigen Beschreibung nicht hervor. --RokerHRO (Diskussion) 17:46, 10. Apr. 2016 (CEST)

"ANSI-Zeichensatz"

So etwas gibt es nicht, die ANSI hat nie Zeichensätze definiert. Das hat auch Microsoft inzwischen eingesehen:

„The term “ANSI” as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft—which became International Organization for Standardization (ISO) Standard 8859-1. “ANSI applications” are usually a reference to non-Unicode or code page–based applications.“ https://msdn.microsoft.com/en-us/goglobal/bb964658.aspx#a --RokerHRO (Diskussion) 17:50, 10. Apr. 2016 (CEST)

Stimmt. Ich wollte damit C0+C1 ausdrücken, also die vollen 8-Bit versus den ASCII-7-Bit.

Obwohl es keinen ANSI-Zeichensatz gibt, gibt es in fast allen Zeichensätzen die ANSI-Steuerzeichen.

Aber, es ist ja noch nicht aller Tage abend. Einfach ändern, was nicht passt. (Ich werde das vielleicht auch machen, jetzt gerade ist aber die Luft raus. Kann nicht mehr…)

‣Andreas•⚖ 19:38, 10. Apr. 2016 (CEST)

Aber gerade Microsoft hat ja bei seinen "Windows Codepages" (die in der Windows-Welt ja leider oft "ANSI-Zeichensatz" genannt werden) an die Code-Positionen 128…159 nicht für Steuerzeichen reserviert sondern mit grafischen Zeichen befüllt. Damit ist der Begriff "ANSI-Steuercodes" noch verwirrender/irreführender, finde ich. --RokerHRO (Diskussion) 06:55, 11. Apr. 2016 (CEST)

Ich wusste nicht, dass unter Windows die CP1252 als „ANSI-Zeichensatz“ bekannt ist. Dass man unter Windows die meisten ANSI-Steuercodes nicht braucht, ist aber auch klar. Unicode hat offenbar trotzdem auf diese Steuerbefehle Rücksicht genommen und sie (funktionell stillgelegt) aufgenommen.

Wenn der „ANSI-Zeichensatz“ ein verwendeter Begriff ist, kann man die Verwirrung darum ja ebenfalls im Artikel aufklären…

‣Andreas•⚖ 17:29, 11. Apr. 2016 (CEST)

ROI – proprietäre Steuersequenz bei der DEC VTxxx?

@Güzel-Marmaras: zu dieser Änderung:

Mit meiner Bearbeitung vom 27. März 2016 hatte ich eine Quelle für "ROI" angegeben, die es nicht mehr gibt, die aber glücklicherweise archiviert wurde:

• https://www.ind-systeme.com//deutsch/produkte/daten/software/download/irnet/doc/de/vtemudis.html

Natürlich kann das auch Blödsinn sein, und natürlich kann man 1. darüber diskutieren, ob das in diesem Artikel überhaupt notwendig ist, das zu erwähnen. Ich dachte mir damals, dass es ganz gut passt, weil viele Terminals (Terminalemulationen) einen VT100-kompatiblen Modus haben, also auf die teils proprietären Funktionen der DEC VTs Rücksicht nehmen (müssen, können, sollen). Und 2. kann man ja auch dann, wenn man es erwähnen will, auch stark kürzen.

Add 1.: Diese proprietäre Funktion (ROI ist gem. Quelle einen Bit vor CSI: CSI ist oktal 233, ROI ist oktal 232) könnte man durch eine andere proprietäre Steuersequenz, als Beispiel, ersetzen, die auf CSI basiert.

Add 2.: Dagegen spricht, dass sich außer der oben angegebenen Quelle offenbar nichts finden lässt, dass sich an Position okt 232 überhaupt eine proprietäre DEC-Escape-Steuersequenz befindet. Auch im (im Artikel als Referenz verlinkten) Handbuch zur DEC VT220 ist die Stelle okt 232 leer, während sich an Stelle okt 233 CSI befindet.

Abseits von ROI, aber zur Bedeutung der DEC VTxxx-Reihe, fällt mMn auch folgende Seite zumindest in die Rubrik good read:

• https://vt100.net/emu/dec_ansi_parser.html, Zitat aus den Footnotes: It appears to be common knowledge among emulator writers (and their critics) that the sequence CSI 2 LF C moves the cursor two columns right and one row down. How many realise that this behaviour is not specified in X3.64, but just happens to have been the error recovery chosen by the designers of the VT100? The lesson I take from this is that if you’re going to emulate a real terminal, you should match all observable behaviour.

--‣Andreas•⚖ 16:17, 22. Mär. 2024 (CET)

Hallo @Y2kbug!

Ich habe deshalb extra in den originalen VT-Dokus nachgesehen. IND-Systems scheint da (wie die SCI Funktion das vorschlägt) eigene Funktionen für ihre Terminals implementiert zu haben, auch wenn die mit der Tatsache, dass die Folgefunktionen dann länger sind als ein Byte, eine Freiheit genommen haben (DEC später mit VT320/VT420 hat das scheinbar auch nicht sonderlich ernst genommen). Aber nachdem über diese IND-Systems und ROI praktisch nichts mehr zu finden ist und es m.E. definitiv falsch ist, dass der SCI (und CSI) in der VT100 vorkommen (VT100 war 7-Bit, CSI kam mit VT220 dazu), hab ich mir halt erlaubt, das vom Volumen her ein bißchen einzudampfen weil dieses Sonderdetail ein bißchen viel Platz einnnahm. Das DEC VT220 Handbuch gibt dem 9A(hex) nicht mal einen eigenen Namen wie Du ja auch festgestellt hast. Ich wollte mit dem Eindampfen nicht respektlos sein, aber mir schien das ein sehr spezifisches Detail das da überproportional Raum einnahm.

DEC hat (nach dem Erfolg der VT100) mit VT220 usw. dann sein eigenes Süppchen gekocht (basierend auf dem prinzipiellen Format wie die ANSI Sequenzen aufgebaut sind) und schlussendlich, als ihnen die Buchstaben ausgingen scheinbar auch das ESC 'Z' für eine Funktion verwurstet. Auf die VT420 aufbauend dann 'xterm' unter Linux nochmal mehr (was inzwischen wieder ins Windows-10 schwappte).

Irgendwann wurde das VT-Zeugs sozusagen ein Quasi-Standard für sich, so dass gute Emulationen sogar Fehler der VT100 nachbauen mußten (google mal 'vttest' wenn Du möchtest). ANSI.X31 lebt eigentlich nur noch im alten MS-DOS und in 90'er Jahre Mailboxen als Standard (ANSI.BBS).

--Güzel-Marmaras (Diskussion) 16:46, 22. Mär. 2024 (CET)

Sure thing! Passt mir gut, ich wollte nur klarstellen, dass es damals eine Quelle gab und ich mir das nicht aus den Fingern gesogen habe...

Ich sehe das ja genauso, es war wohl zu viel Detail mit zu wenig Nutzen. Darum danke. Auch für diese Diskussion: so soll es sein!

Der Artikel ist übrigens immer noch verbesserungswürdig. Man könnte noch viel mehr "Alltagsbeispiele" einbauen, die wirklich Sinn machen. Mir ist damals allerdings irgendwann der Atem ausgegangen...

Gruß, ‣Andreas•⚖ 17:11, 22. Mär. 2024 (CET)

Ja, ich seh da schon noch die eine oder andere Verbesserungsmöglichkeit, ist aber auch gut dass Du erwähnst, dass Dir der Atem ausgegangen ist, sonst hätte ich mich zurückgehalten (will nicht jemandem zu viel in einen Artikel hineinpfuschen der so eine Art Steckenpferd ist). Ist aber ein guter Artikel, an den Tabellen usw. sieht man, dass sich da schon jmd Mühe gegeben hat (warst wohl Du, so wie ich das in der Diskussion sehe).

--17:20, 22. Mär. 2024 (CET) --Güzel-Marmaras (Diskussion) 17:20, 22. Mär. 2024 (CET)

Der Artikel ist zwar von mir, aber ich habe gar nichts dagegen, wenn ihn jemand "adoptiert" oder mehrere Autoren das eine oder andere verbessern. Es ist natürlich so, dass ich die Bearbeitungen in meiner Beobachtungsliste sehe, und wenn ich etwas nicht ganz verstehe, frage ich nach. Oder wie hier, um darauf hinzuweisen, was meine Intention war. Ich habe die Erfahrung gemacht, dass Diskussionen, auch wenn sie mal hitzig sein sollten, den Artikel meistens trotzdem positiv voranbringen. In diesem Fall ist die Diskussion zwar nicht hitzig, aber vielleicht führt es ja dennoch zu einer weiteren Artikel-Verbesserung.

Ja, die Luft ist raus. Ich habe den Artikel nur geschrieben, weil er meiner Meinung nach notwendig war, und weil er gefehlt hat.

Die Sache mit Windows und xterm ist interessant. Vielleicht sollte man das einbauen.

Zu den Edits: kleinere Veränderungen mit nachvollziehbarer Zusammenfassung sind der Weg, damit Co-Autoren sich auskennen. Das hast du gemacht, und darum konnte ich angemessen reagieren: deine Zusammenfassung war "Inhalt ohne Beleg eingestampft", was meine Reaktion "Belege gab es, aber vermutlich schlechte... und generell verstehe ich, dass der Inhalt zu viel und unnötig ins Detail geht" ausgelöst hat.

Zum weiteren Vorgehen: meine Luft ist immer noch raus. Was mir jedoch einfällt, ist, dass man noch ein praktisches Beispiel einfügen könnte, etwa wie man in xterm oder der Windows-Eingabeaufforderung (oder der neuen Terminal-Anwendung) farbigen Text ausgeben könnte... oder sonst was praxisnahes.

Und mir ging die Entwicklungsgeschichte nicht leicht von der Hand. Wie du geschrieben hast, gibt es da einen Weg von der DEC VT52, die Nicht-ANSI-Escapesequenzen einführte, zur VT100 mit Escapesequenzen nach ANSI X3.64 (eigentlich ECMA-48), und hin zur VT200 und neueren. Irgendwo zweigt sich echtes "ANSI" à-la ANSI-BBS (ANSI.SYS) ab, das mit den proprietären Erweiterungen nichts am Hut hat. Allerdings haben die "De-facto-Standards" VT52, VT100 und VT200 in so gut wie alle Unix-Terminals Einzug gehalten (xterm).

Mein Problem war allerdings, dazu eine geeignete Quelle zu finden. Da ich nichts fand, steht das alles nicht im Artikel. Und: es könnte ja auch falsch sein. Ohne Quelle ist das nur meine Vermutung, wie es geschichtlich sein könnte. Aber war es wirklich so?

Long story short: wenn du dich mit der Materie auskennst und motiviert bist: leg los! Nur zu, der Artikel ist nicht "mein Baby", ich bin nicht böse, wenn ihn jemand verbessert. (Auch eine Straffung kann eine Verbesserungen sein, wie im vorliegenden Fall.)

‣Andreas•⚖ 22:40, 22. Mär. 2024 (CET)

Adoptieren werde ich ihn wahrscheinlich nicht, aber an das mit praktischen Beispielen hatte ich auch schon gedacht. Und wenn ich weiß dass der Originalautor da noch ein Auge drauf hat, werde ich entsprechend rücksichtsvoll vorgehen (ich hab übrigens "eingedampft" (reduziert, distilliert) geschrieben, nicht eingestampft ;-).

--Güzel-Marmaras (Diskussion) 09:51, 23. Mär. 2024 (CET)

Oh. Sorry. Freudscher Verleser...

Und zum Originalautor: In der Wikipedia hat ja niemand seinen Artikel. Es gibt ja keinen Besitzanspruch. So habe ich das immer gesehen, und ich bin auch immer dankbar, wenn jemand mithilft.

‣Andreas•⚖ 11:00, 23. Mär. 2024 (CET)

Ich hab da mal ein bißchen Umstrukturiert, aber habe versucht Deine Teile möglichst stehen zu lassen (nur in anderer Reihenfolge/Kombination). Der Versionsvergleich sieht teilweise aus als hätte ich Teile gelöscht, weil der das Überkreuzverschieben von Absätzen nicht versteht, aber Deine Aussagen mit Quellen sind z.B. alle noch drin. --Güzel-Marmaras (Diskussion) 12:28, 23. Mär. 2024 (CET)

LOL, das ist jetzt bißchen ausgeartet, aber dafür hat's jetzt auch Beispiele. Fühl dich frei da bißchen Grobheiten auszubügeln oder Anglizismen einzudeutschen oder sowas, ich bin erstmal fertig (bzw. muß das ggf. mit etwas Abstand nochmals Korrekturlesen). Und danke für den "Dank". --Güzel-Marmaras (Diskussion) 15:11, 23. Mär. 2024 (CET)

Ist ein schöner Artikel geworden soweit, danke für die Vorarbeit --Güzel-Marmaras (Diskussion) 17:27, 23. Mär. 2024 (CET)

Ich übergebe den Artikel damit wieder vertrauensvoll in die Hände des "Originalautors" (auch wenn es sowas auf Wikipedia gar nicht gibt ;-) --Güzel-Marmaras (Diskussion) 17:30, 23. Mär. 2024 (CET)

(Bin froh, dass sich der freudsche Verleser geklärt hat ... ich wollte Deinen Teil nicht "platt machen" (einstampfen) sondern nur im Volumen ein bisschen reduzieren, aber die Essenz bewahren (eindampfen/destillieren). --Güzel-Marmaras (Diskussion) 19:07, 23. Mär. 2024 (CET)

Farben

Ein interessanter Aspekt sind die SGR Funktionen mit Farben. DEC hat bis zum Schluss nur monochrome Terminals hergestellt, während der ANSI ECMA-48 Standard von Anfang an beim SGR auch Farben für Vorder- und Hintergrund definierte (Ps= 30-37 und 40-47). Dies wurde von DOS/Windows von Anfang an unterstützt, floss aber erst durch Unix/xterm oder ANSI-SCO in Terminal-Implementierungen ein. Das geht zwar für den Artikel wahrscheinlich zu weit, ist aber ein interessantes Detail, das mir auffiel, als ich mir SGR unter VT100/VT220 ansah. Andererseits implementierte VT100 von Anfang an Funktionen, die im ECMA nicht enthalten waren (die Funktionsnamen fangen dann alle mit DEC an oder sind unter "dec private" attributiert) (cc @Y2kbug:).