[10.8 Mountain Lion] Terminal paar Fragen

[Bananenbieger]

cat ist ein Programm. Alle Ein- und Ausgabe im Terminalfenster wird dann über cat abgewickelt. Terminal.app leitet nur Tasteneingaben und Ausgaben durch.

Oder um es mal anders darzustellen: Wenn Du über Remote-Desktop Word öffnest, dann ist Remote Desktop trotzdem noch keine Textverarbeitung

 

[Marcel Bresink]

cat ist ein Programm. Alle Ein- und Ausgabe im Terminalfenster wird dann über cat abgewickelt. Terminal.app leitet nur Tasteneingaben und Ausgaben durch.

Nein, es macht mehr. Auch Du hast offenbar die Architektur des Programms Terminal nicht verstanden. Das Programm cat arbeitet in diesem Fall quasi als Filter, der auf die Ein-und Ausgabesteuerung des Texteditors Einfluss nimmt.

Versuche mal, darüber nachzudenken, warum Terminal die Funktion "Resume" unterstützen kann, warum es über die oberste Zeile des emulierten Terminals zurückscrollen kann und warum man den gesamten Inhalt als txt-Datei abspeichern oder sie als mehrseitiges Dokument drucken kann.

Lange laufende Befehlszeilenprogramme konnten in älteren Versionen von Mac OS X übrigens das Terminal zum Absturz bringen. Der Grund war, dass der eingebaute Texteditor, wie damals für 32-Bit-Programme üblich, bei einer Textmenge von 2 GByte übergelaufen ist, weil für den internen Zeilenpuffer kein Speicher mehr allokiert werden konnte.

Aber Du stimmst mir ja offenbar zu, dass das Teminal an der Befehlsverarbeitung, die innerhalb seiner Fenster abläuft, direkt in keiner Weise beteiligt ist.

 

[Bananenbieger]

Du kannst auch aus Konsole.app Text kopieren, in Dateien speichern etc.

Ein Terminal ist ein Terminal. Ein Texteditor ist ein Texteditor.

Wäre ein Terminal ein Texteditor, müsstest Du den Cursor x-beliebig platzieren und Text an beliebiger Stelle modifizieren können. Das ist aber nicht möglich, ohne im Terminal einen Texteditor zu starten (nano, vim, emacs...).

Wenn ich cat /dev/urandom > terminal.txt mache, dann würde laut Deiner Angabe die Datei terminal.txt selber zum Texteditor...

 

[Marcel Bresink]

Du kannst auch aus Konsole.app Text kopieren, in Dateien speichern etc.

Das Programm Konsole unterstützt zwei verschiedene Typen von Dokumentenfenstern: Der Live-View auf die ASL-Datenbank ist kein Texteditor. Alle Fenster zur Darstellung von Log-Dateien als Text sind jedoch in der Tat Texteditoren, die auf "setEditable: NO" konfiguriert sind und daher keine Tastatureingabe unterstützen.

Ein Terminal ist ein Terminal. Ein Texteditor ist ein Texteditor.

Es hat niemand etwas anderes behauptet. Trotzdem basiert das Terminal von OS X auf einem raffiniert angepassten Texteditor.

Wäre ein Terminal ein Texteditor, müsstest Du den Cursor x-beliebig platzieren und Text an beliebiger Stelle modifizieren können.

Nein, dann wäre ja die Terminaleigenschaft nicht mehr erfüllt.

Wenn Du dort ein "a" tippst, läuft das durch eine Tastenkonvertierungtabelle, dann in den Eingabekanal des angesprochenen Kindprozesses und kommt (je nach Kindprogramm) vielleicht aus dem Ausgabekanal wieder heraus. Das "a" wird danach an der aktuellen Schreibmarkenposition in den Editor geschrieben.

Wenn Du dort "Pfeil nach oben" drückst, findet der gleiche Prozess statt, nur mit den entsprechenden Steuerzeichen. Läuft nun "cat" als Kindprozess, werden die Steuerzeichen interpretiert und in lesbare Zeichen übersetzt. Dabei wird z.B. aus dem "Escape" ein "^". Wäre jedoch der Kindprozess eine Shell, die als Kindprozess einen Befehlszeileneditor laufen hat, würde eine Steuersequenz der Terminalemulation für "Cursor hoch" geliefert werden, z.B. "<ESC>[1A". Der Editor des Terminals speichert nun kein Zeichen ab, sondern führt einen "Cursor hoch"-Befehl aus. Ist der Kindprozess dagegen nur die bash, wird die Shell ihre History-Funktion aufrufen und die letzte eingegebene Zeile auf ihrem Ausgabekanal liefern. Dann wird diese Zeile entsprechend im Editor des Terminals landen.

Wenn ich cat /dev/urandom > terminal.txt mache, dann würde laut Deiner Angabe die Datei terminal.txt selber zum Texteditor

Nein. Eine Datei führt keine interaktive Textverarbeitung aus.

 

[Scotch]

Marcel, du machst dich hier vollkommen lächerlich. Du hast scheinbar nicht mal den Unterschied zwischen einer Shell und einem CLI verstanden. Du bringst auch munter Cocoa-Funktionen, Terminal-Funktionen und und Terminal.app Funktionen durcheinander.

Lass' einfach gut sein.

 

[Marcel Bresink]

Ich konnte alle Behauptungen durch Fakten belegen, die jeder an seinem OSX-System überprüfen kann. Schade, dass Du außer Überheblichkeiten nichts zum Thread beigetragen hast.

Jeder Leser kann sich selbst ein Urteil bilden.

 

[Bananenbieger]

Alle Behauptungen, die Du aufgestellt hast, hast Du doch in Deinen eigenen Beiträgen widerlegt.

Merke: Ein Mensch hat zwei Arme - aber nicht alles, was zwei Arme hat, ist auch ein Mensch. Genauso ist es hier. Terminal verarbeitet zwar Text, ist aber noch kein Texteditor.

Alle Fenster zur Darstellung von Log-Dateien als Text sind jedoch in der Tat Texteditoren, die auf "setEditable: NO" konfiguriert sind und daher keine Tastatureingabe unterstützen.

Nein, die Dinger heißen nicht umsonst z.B. NSTextField und nicht NSTextEdit! "setEditable:NO" nimmt NSTextField die Editoreigenschaft.

Nein, dann wäre ja die Terminaleigenschaft nicht mehr erfüllt.

Genau, und deswegen ist ein Editor ein Editor und ein Terminal ein Terminal. Ein Webbrowser ist auch ein Webbrowser, obwohl er editierbare Textfelder darstellen kann usw.

Remote Desktop ist übrigens ebenfalls ein Terminal, kein Texteditor, kein Grafikeditor und auch kein Videoeditor!

Nein. Eine Datei führt keine interaktive Textverarbeitung aus.

Terminal auch nicht. Copy & Paste etc. sind keine Textverarbeitungsfunktionen. Und jegliche Funktion, die überhaupt einer Textverarbeitung gleich käme, wird durch andere Programme (nano, vim, ed etc.) bereitgestellt.

 

[Marcel Bresink]

Merke: Ein Mensch hat zwei Arme - aber nicht alles, was zwei Arme hat, ist auch ein Mensch. Genauso ist es hier. Terminal verarbeitet zwar Text, ist aber noch kein Texteditor.

Und wenn ein Mensch seine Arme verliert, ist er nach Deiner Meinung offenbar kein Mensch mehr. Brauchst Du Nachhilfe in Prädikatenlogik erster Stufe?

Ich habe gezeigt, mit welchem technischen Trick man nachweisen kann, dass das OSX-Terminal im Bezug auf seine Rolle als Befehlszeilenzugang lediglich Textverarbeitungsfunktionen übernimmt, indem man prüft, was übrig bleibt, wenn man jegliche Befehlsverarbeitung, Shell, etc. deaktiviert. Solange Du als Editiertaste nur Backspace benötigst, kannst Du mit diesem auf seinen Kern reduzierten Terminalprogramm beliebig lange Texte schreiben, speichern und drucken.

Nein, die Dinger heißen nicht umsonst z.B. NSTextField und nicht NSTextEdit!

Sicher ist es Dir entgangen, dass die Editor-Funktionalität in OS X üblicherweise von NSTextView übernommen wird und dass auch ein NSTextField ein als Overlay-Mini-Window realisierten Texteditor (!) der NSTextView-Klasse zu Hilfe nimmt, sobald Du die Schreibmarke in dessen Feld setzt.

Aber wenn man auf der Logik besteht, dass ein Auto, bei dem man die Räder abmontiert hat, auf gar keinen Fall als Auto bezeichnet werden darf, weil es nicht fährt, dann kannst Du natürlich solche Dinge behaupten.

 

[Bananenbieger]

Ich habe gezeigt, mit welchem technischen Trick man nachweisen kann, dass das OSX-Terminal im Bezug auf seine Rolle als Befehlszeilenzugang lediglich Textverarbeitungsfunktionen übernimmt, indem man prüft, was übrig bleibt, wenn man jegliche Befehlsverarbeitung, Shell, etc. deaktiviert.

Du hast /bin/cat im Terminal gestartet und gezeigt, was cat kann.

Sicher ist es Dir entgangen, dass die Editor-Funktionalität in OS X üblicherweise von NSTextView übernommen wird und dass auch ein NSTextField ein als Overlay-Mini-Window realisierten Texteditor (!) der NSTextView-Klasse zu Hilfe nimmt, sobald Du die Schreibmarke in dessen Feld setzt.

Mea culpa, ich muss halt immer kurz in die Doku schauen, da ich im Beruf jetzt eher mit den in der Cloud anzutreffenden Sprachen/Frameworks zu tun habe.
Ob NSTextView oder NSTextField spielt aber keine Rolle. Ein wie auch immer geartetes Textfeld macht noch lange keinen Texteditor.
Selbst Apple achtet furchtbar genau darauf, dass "text system" nicht "text editor" zu nennen, z.B. hier: https://developer.apple.com/library...on/Intro.html#//apple_ref/doc/uid/DTS40011741

Aber wenn man auf der Logik besteht, dass ein Auto, bei dem man die Räder abmontiert hat, auf gar keinen Fall als Auto bezeichnet werden darf, weil es nicht fährt, dann kannst Du natürlich solche Dinge behaupten.

Nein, auch das ist ein Fehlschluss Deinerseits. Das Auto hat prinzipiell Räder wie auch der Mensch prinzipiell Arme hat. Sollten die aus welchen Gründen auch immer Fehlen, so bleibt Auto zwar Auto und Mensch bleibt Mensch, dennoch ändert sich nichts daran, dass Autos üblicherweise Räder und Menschen üblicherweise Arme haben.

 

[Marcel Bresink]

Du hast /bin/cat im Terminal gestartet und gezeigt, was cat kann.

Nein, nein, nein. Du hast offenbar wirklich nicht verstanden, wie dieser Trick arbeitet. Nochmal: Probiere genau das aus, was ich geschrieben habe und staune.

Der durch cat laufende Kindprozess schließt die Ein-/Ausgabeverarbeitung des Terminals so kurz, das dessen Grundfunktionen durch nichts mehr überlagert werden, außer durch die Terminal-Emulation.

 

[Bananenbieger]

Ne, lieber Marcel. Ein-/Ausgabe werden in Deinem Beispiel alleinig von cat durchgeführt. Das wird nichts kurzgeschlossen, sondern ganz ordentlich Tasteneingaben angenommen und von cat ausgegeben.
Du müsstest spätestens hier erkennen, dass Terminal kein Texteditor, sondern einfach nur Tasteneingaben versendet und Textausgaben seitens cat rendert.

Es lässt sich einfach zeigen, dass Terminal an sich keinerlei Editorqualitäten hat. Einfach folgendes C-Programm kompilieren und ausführen.

[COLOR=#339933]#include <stdio.h>[/COLOR]
main[COLOR=#009900]([/COLOR][COLOR=#009900])[/COLOR][COLOR=#009900]{ [/COLOR][COLOR=#000066]  printf[/COLOR][COLOR=#009900]([/COLOR][COLOR=#FF0000]"Editier mich![COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR]  [COLOR=#B1B100]while[/COLOR][COLOR=#009900]([/COLOR][COLOR=#0000DD]1[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900]{[/COLOR]  [COLOR=#009900]} [/COLOR][COLOR=#009900]}[/COLOR]

"Editier mich!" wirst Du über Terminal nicht modifizieren können, womit eine grundlegende Voraussetzung für die Deklaration als Texteditor fehlt.

 

[Marcel Bresink]

"Editier mich!" wirst Du über Terminal nicht modifizieren können

Das liegt daran, dass Dein Programm seinen stdin-Kanal nicht verwendet und somit als Filterkindprozess unbrauchbar ist.
Das korrekte Programm ist wie folgt:

#include <stdio.h>

int main(void)
{
    while (putchar(getchar()));
    return 0;
}

Tippe nun den Text "Editier mich!" ein und speichere ihn mit dem Terminal (cmd+S) als Textdatei. Du kannst auch das ganze Fenster volltippen (ohne Return) und danach mit dem Scrollbar auf den oberen Teil des Textes zurückblättern. Wer speichert wohl diesen Text? Das Miniprogramm ist es nicht …

 

[Bananenbieger]

Marcel, Du hast da einen simplen "Editor" in C geschrieben. Das hat mit dem Terminal rein gar nichts zu tun.

PS: "Editier mich!" ist auch in dem Fall nicht editierbar, was gleich doppelt die Eigenschaft von Terminal als Texteditor vernichtend widerlegt.

 

[Marcel Bresink]

Da bist Du auf dem Holzweg. Aber schön dass Du mir zutraust, einen kompletten grafischen Texteditor als Einzeiler zu programmieren.

Wenn Dich das immer noch nicht überzeugt, verwende dieses Filterprogramm:

#include <stdio.h>
#include <termios.h>

int main(void)
{
    struct termios iomode = { 0 };
    int c;

    printf("Editier mich!");
    tcgetattr(0, &iomode);
    cfmakeraw(&iomode);
    tcsetattr(0, TCSANOW, &iomode);
    while ((c = getchar())) {
       if (c == 127)
           c = 8;
       putchar(c);
       if (c == '\r') 
          putchar('\n');
    }
    return 0;
}

 

[Bananenbieger]

Ähm, Marcel, das ist ein externes Programm (das Präfix "Filter" vergesse bitte mal ganz schnell).

Dass Du überhaupt solche Programme brauchst, zeigt doch ganz klar, dass Terminal eben kein Texteditor ist (der würde das schließlich schon von sich aus können).

Nochmal: Terminal ist eine ganz stupide Eingabe/Ausgabe-App für textbasierte Programme - Und kein Texteditor. Analog gilt für GUI-Terminals wie VNC das gleiche (sind auch keine Grafikeditoren). Eingaben werden vom Terminal zum Hostsystem durchgereicht, Ausgaben vom Hostsystem zum Terminal. Dass man aus Terminals Text- oder Grafikelemente kopieren bzw. in diese einfügen kann, ist für die Eigenschaft als Editor vollkommen irrelevant.

 

[Marcel Bresink]

Ähm, Marcel, das ist ein externes Programm

Ja natürlich. Wie jetzt schon mehrmals beschrieben, ersetzt dieses Programm den Kindprozess, den das Terminal normalerweise in seiner Standardkonfiguration für jedes Fenster aufruft. Das externe Programm, das im Normalfall verwendet wird, ergäbe sich sonst durch den shell-Eintrag des aufrufenden Benutzer-Accounts.

das Präfix "Filter" vergesse bitte mal ganz schnell

Du solltest mal ganz schnell diesen Thread lesen und versuchen zu begreifen, mit welcher Technik Apple das OSX-Terminal realisiert hat. Der erwähnte Kindprozess arbeitet als Filter zwischen Ein- und Ausgabe eines speziellen Texteditors.

Dass Du überhaupt solche Programme brauchst, zeigt doch ganz klar, dass Terminal eben kein Texteditor ist (der würde das schließlich schon von sich aus können).

Nein, da in dem winzigen Programm, wie jeder sehen kann, keine Editorfunktionen stecken, bleibt nur das Terminal als ausführender Editor übrig. Das Austauschen des Hilfsprogramms dient nur dazu, die innerhalb des Terminal-Fensters ablaufenden Funktionen, die sonst von der Terminal-Emulation, der Shell und den eventuell als Enkelprozess gestarteten Programmen überlagert werden, zu deaktivieren, damit das Terminal sein wahres, unbeeinflusstes Verhalten zeigt.

Was fehlt Dir noch, um die versteckte Editor-Funktionalität des Terminals zu erkennen? Vermisst Du z.B. eine Rechtschreibprüfung?

Terminal ist eine ganz stupide Eingabe/Ausgabe-App für textbasierte Programme

Nein. Das mag ja bei den meisten anderen Terminal-Programmen auf anderen Betriebssystemen sowie Hardware-Terminals der Fall sein, gilt jedoch nicht für das Terminal-Programm von OS X. Apple verwendet eine besondere Architektur, um dieses Programm mit Komfortfunktionen anzureichern, die Standard-Terminals nicht haben.

 

[Bananenbieger]

Ja natürlich. Wie jetzt schon mehrmals beschrieben, ersetzt dieses Programm den Kindprozess, den das Terminal normalerweise in seiner Standardkonfiguration für jedes Fenster aufruft.

Und spätestens da müsste Dir doch das Licht aufgehen, dass der Kindprozess für die ganze Magie zuständig ist. Dem ist es nämlich egal, ob er direkt auf eine Hardware oder an eine Terminal.app rendert.

Du solltest mal ganz schnell diesen Thread lesen und versuchen zu begreifen, mit welcher Technik Apple das OSX-Terminal realisiert hat. Der erwähnte Kindprozess arbeitet als Filter zwischen Ein- und Ausgabe eines speziellen Texteditors.

Vom Wiederholen wird das nicht richtiger. Terminal.app spuckt das aus, was das ausgeführte Programm rausschmeisst. Da ist deswegen genau null Editor-Funktionalität im Terminal enthalten.

Nein, da in dem winzigen Programm, wie jeder sehen kann, keine Editorfunktionen stecken, bleibt nur das Terminal als ausführender Editor übrig.

Äh, nein. Erkennt man doch direkt an den Includes.

Was fehlt Dir noch, um die versteckte Editor-Funktionalität des Terminals zu erkennen?

Was fehlt Dir, um zu erkennen, dass die gesamte Magie in den Kindprozessen steckt?

Nein. Das mag ja bei den meisten anderen Terminal-Programmen auf anderen Betriebssystemen sowie Hardware-Terminals der Fall sein, gilt jedoch nicht für das Terminal-Programm von OS X.

Das gilt für alle Terminals, andernfalls wären sie als Terminals nicht zu gebrauchen.

 

[Marcel Bresink]

Und spätestens da müsste Dir doch das Licht aufgehen, dass der Kindprozess für die ganze Magie zuständig ist.

Auch da fehlen Dir die Grundlagen. Der Kindprozess rendert gar nichts. Er sendet einen Bytestrom an das Terminal. Gemäß der Interpretation dieses Bytestroms, den die aktive Terminal-Emulation vorgibt, rendert dann der Texteditor des Terminals die sich ergebenden Glyphen, bzw. führt intern die Edit-Funktionen nach.

Der normalerweise aufgerufene Kindprozess wird durch so etwas wie

/usr/bin/login -f $USER -p CHILDPATH

realisiert, wobei CHILDPATH durch den Pfad ersetzt wird, der sich durch die Benutzerpräferenz für "Start > Shells öffnen mit" ergibt.

Da ist deswegen genau null Editor-Funktionalität im Terminal enthalten.

Nein, das ist falsch, denn das Terminal verarbeitet und speichert zusätzlich zu der reinen Ausgabe den Text zwischen. Ansonsten wäre "endloses" Zurückrollen, Exportieren und Resume des Fensterinhaltes nicht möglich. Du konntest auch nach mehrmaliger Nachfrage nicht beantworten, woher diese Funktionalität ansonsten kommt.

Äh, nein. Erkennt man doch direkt an den Includes.

Du redest Dich um Kopf und Kragen.

Was fehlt Dir, um zu erkennen, dass die gesamte Magie in den Kindprozessen steckt?

Du brauchst nur zu erklären, wer - wenn nicht das Terminal selbst - die Textverarbeitungs-, Speicher-, Such- und Druckfunktionen übernimmt, die immer noch alle funktionieren, auch wenn der Kindprozess so wie dargestellt manipuliert wird, dass er außer einem Durchreichen des Bytestroms nichts mehr tut, insbesondere keinen Text speichert.

 

[Bananenbieger]

Der Kindprozess rendert gar nichts. Er sendet einen Bytestrom an das Terminal.

Vulgo: Er rendert, denn der Bytestrom enthält Zeichnungsanweisungen für ein textbasiertes Endgerät. Identisch funktioniert das Rendern von Grafiken an eine Grafikkarte. Fast identisch funktioniert das Rendern an einen Plotter (hier fehlt die Möglichkeit, etwas bereits ausgegebenes zu löschen).
Die Funktionsnamen "print" oder "printf" heißen nicht umsonst so...

Du brauchst nur zu erklären, wer - wenn nicht das Terminal selbst - die Textverarbeitungs-, Speicher-, Such- und Druckfunktionen übernimmt, die immer noch alle funktionieren, auch wenn der Kindprozess so wie dargestellt manipuliert wird, dass er außer einem Durchreichen des Bytestroms nichts mehr tut, insbesondere keinen Text speichert.

Textverarbeitungsfunktion -> Keine Anhaltspunkte dafür, dass Terminal.app diese besitzt
Speicherfunktion -> Keine Anhaltspunkt für einen Texteditor
Suchfunktion -> Kein Anhaltspunkt für einen Texteditor
Druckfunktion -> Kein Anhaltspunkt für einen Texteditor

Was bitte soll ich denn jetzt Dir hier erklären?
Safari kann Texte verarbeiten, Dateien speichern, Textschnipsel suchen und auch drucken - Und dennoch kommt niemand auf die Idee, Safari als Texteditor darzustellen. Dass Du einen (Zeilen-)Puffer als Texteditor bezeichnest, ist schon eine sehr kreative Auslegung.

 

[Marcel Bresink]

Er rendert, denn der Bytestrom enthält Zeichnungsanweisungen für ein textbasiertes Endgerät.

Du kennst also auch die Bedeutung des Wortes "Rendern" nicht?

Und dennoch kommt niemand auf die Idee, Safari als Texteditor darzustellen.

Außer in einer HTML-Textarea kann ich in Safari auch keinen Text eintippen und diesen verändern. Ebenso wäre es nicht sinnvoll, die Funktionen von Safari intern über Editortechniken zu realisieren, da sich daraus kein Nutzen ergäbe. Beim Terminal ist das anders.

Textverarbeitungsfunktion -> Keine Anhaltspunkte dafür, dass Terminal.app diese besitzt

Die Anhaltspunkte wurden nun mehrfach aufgezeigt. Wenn Du logischen Argumenten nicht zugänglich bist, kann man leider nicht mehr helfen.