Simon Tatham hat Tron Legacy angehalten, das Terminal-Fenster studiert und daraus eine eintägige Lerneinheit für einen Nachwuchskollegen gemacht. Herausgekommen ist eine der genauesten Filmanalysen, die je jemand über 30 Zeilen Befehlsverlauf geschrieben hat.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 5 Abschnitte
Das Wichtigste in Kürze
- Simon Tatham, Entwickler von PuTTY, analysierte am 28. Mai 2026 die Terminal-Szene in Tron Legacy (2010) als Lernübung für einen Nachwuchskollegen.
- Das Shell-Protokoll im Film ist überraschend stimmig: ein eigenes Konfigurationsskript, eine doppelte Sicherung an der Lasersteuerung und ein zweites Root-Konto mit plausibler Erklärung.
- Klare Fehler:
bin/historystatt des eingebautenhistory-Befehls verrät ein Skript hinter dem Verlauf, und dieuname-Ausgabe nennt Kennungen für SPARC- und x86-Hardware zugleich. - Keine Erklärung fand Tatham auch 16 Jahre nach dem Kinostart für das Terminal mit Proportionalschrift und Wortumbruch.
Welche Unix-Details hat das Filmteam richtig hinbekommen?
Das Protokoll beginnt mit whoami, zeigt dann einen fehlgeschlagenen Root-Login und den Wechsel zum Konto backdoor, das ebenfalls die UID 0 hat. Jemand im Produktionsteam kannte Unix gut genug, um zu wissen, dass zwei Konten dieselbe UID haben können und dann denselben Befehlsverlauf lesen. Für plausibel hält Tatham die Deutung, dass Sam Flynn die Hintertür selbst angelegt hatte, um seinen zunehmend verschlossenen Vater im Auge zu behalten.
Der Eintrag ./configure -o test.cfg im Verlauf ist kein Autoconf-Aufruf, sondern der Aufruf eines eigenen Konfigurationsskripts der Lasersteuerung. Den Hinweis liefert der Parameter -o, den Autoconf-Skripte nicht kennen. Beim ersten Ansehen hatte Tatham den Aufruf für einen Fehler gehalten und revidierte sein Urteil erst bei der Analyse mit dem Kollegen.
Auch die doppelte Sicherung der Lasersteuerung überzeugt: Erst legt touch /opt/LLL/run/ok eine leere Datei als Freigabe an, dann verlangt der Aufruf ausdrücklich den Parameter -ok 1. Beide Techniken kommen in echter Unix-Software vor. Git nutzt beide Muster: git-daemon verlangt eine Datei git-daemon-export-ok im Repository, und git-clean löscht nur mit ausdrücklichem -f.
Das Konto backdoor hat wie root die UID 0 und damit Zugriff auf denselben Befehlsverlauf.
./configure -o test.cfg passt nicht zu Autoconf, wohl aber zu einem eigenen Skript der Lasersteuerung.
touch /opt/LLL/run/ok legt eine leere Datei an, die den Laser freigibt, wie git-daemon-export-ok bei Git.
Der Aufruf verlangt zusätzlich -ok 1; nach demselben Muster löscht git-clean nur mit -f.
Diese Analyse zeigt, wie viel handwerkliche Qualität in guter Dokumentation und Code-Review steckt. Wer Shell-Transcripts richtig liest, lernt mehr über Unix als aus manchem Lehrbuch.
Michael Dobler, Herausgeber Dr. Web
Wo lagen die Filmemacher daneben?
Der offensichtlichste Fehler ist bin/history statt des eingebauten Shell-Befehls history. Der Befehlsverlauf liegt in der laufenden Shell-Instanz, und kein externes Programm kommt an ihn heran. Tatham vermutet, dass das Produktionsteam ein einfaches Skript namens bin/history verwendet hat, das den für die Handlung gewünschten Verlauf ausgibt, während das echte System eine andere Vorgeschichte hatte.
Verraten hat sich das Skript durch den letzten Eintrag, der nicht der gerade ausgeführte Befehl ist: Ein echtes history würde sich selbst am Ende der Liste zeigen. Mit einem Shell-Alias wäre der Trick unsichtbar geblieben.
Die Ausgabe von uname -a nennt sowohl sun4m als auch i386, und beides passt technisch nicht zusammen: sun4m bezeichnet SPARC-Hardware, i386 die x86-Architektur. Ein echter Solaris-Rechner auf x86 hätte i86pc gemeldet. Auch die Prozessnamen in der linken Terminal-Spalte verraten ein anderes System, etwa kthreadd und ksoftirqd: Beide sind Kernel-Threads von Linux, nicht von Solaris.
Tatham schließt daraus, dass das Produktionsteam auf einem echten Linux-Rechner arbeitete, die uname-Ausgabe von Hand auf ein fiktives SolarOS umschrieb und dabei übersah, dass die anderen Fenster dieselbe Maschine zeigen.
Shell-Protokolle lesen zu können, hilft beim Programmieren in jeder Sprache, ob in Python, Rust oder im klassischen C, in dem PuTTY geschrieben ist. Welche Sprachen 2026 vorn liegen, zeigt der große Vergleich auf drweb.de.
Der Befehlsverlauf liegt in der laufenden Shell, ein externes Programm kommt nicht an ihn heran.
Die uname-Ausgabe nennt SPARC- und x86-Kennungen zugleich; Solaris auf x86 meldet i86pc.
kthreadd und ksoftirqd sind Kernel-Threads von Linux, nicht von Solaris.
Ein Terminal-Fenster nutzt eine Proportionalschrift und bricht Zeilen am Wortende um, das top-Fenster daneben arbeitet korrekt mit Festbreitenschrift.
Was bleibt nach 16 Jahren ungeklärt?
Das Terminal-Fenster im Hauptbild verwendet eine Proportionalschrift statt einer Festbreitenschrift und bricht Zeilen am Wortende um, wie ein Texteditor. Ein normales Terminal bricht die Zeile genau am Fensterrand um, auch mitten im Wort. Ob das Filmteam die Schrift absichtlich oder versehentlich so eingestellt hat, lässt Tatham offen. Das top-Fenster links im selben Bild arbeitet dagegen korrekt mit Festbreitenschrift, die drei Terminal-Fenster im Bild folgen also keiner einheitlichen Schrift.
Seinen letzten Willen legt Flynn als ~/last_will_and_testament.txt im Home-Verzeichnis von Root ab, das laut System auf / liegt. Als Textdatei ohne Zeugen und Unterschrift hätte das Testament keine rechtliche Wirkung. Tatham kommentiert trocken, ein Mann kurz vor der eigenen Digitalisierung per Laser denke wahrscheinlich nicht mehr ganz klar.
Die komplette Analyse steht auf Tathams persönlicher Website und lohnt sich für alle, die Unix nicht nur nutzen, sondern verstehen wollen. Tathams Methode, jede Zeile gegen das echte System zu prüfen, hilft auch, wenn Sie in einem HTML-Editor unerwartetes Verhalten untersuchen oder auf Linux-Servern mit SSH-Clients wie PuTTY arbeiten.
Entwickler, die unter Windows mit Unix-Werkzeugen arbeiten, können die Befehle aus der Szene direkt nachvollziehen: Die Windows-Entwicklungsumgebung 2025 bringt WSL und ein richtiges Terminal mit. Den sicheren Umgang mit der Shell ersetzt auch 2026 keine KI vollständig.
Häufige Fragen zur Unix-Szene in Tron Legacy
Von wem stammt die Analyse der Unix-Szene in Tron Legacy?
Die Analyse stammt von Simon Tatham, dem Entwickler des SSH-Clients PuTTY. Tatham veröffentlichte die Analyse am 28. Mai 2026 auf seiner persönlichen Website und nutzte die Terminal-Szene des Films von 2010 als eintägige Lerneinheit für einen Nachwuchskollegen.
Welche Unix-Details zeigt Tron Legacy korrekt?
Das Konto backdoor teilt mit root die UID 0 und damit denselben Befehlsverlauf. Der Aufruf ./configure -o test.cfg gehört zu einem eigenen Konfigurationsskript der Lasersteuerung. Die doppelte Sicherung aus Freigabedatei und dem Parameter -ok 1 folgt Mustern aus echter Unix-Software wie Git.
Welche Fehler enthält die Terminal-Szene?
Im Film steht bin/history statt des eingebauten Shell-Befehls history. Die uname-Ausgabe nennt mit sun4m und i386 zugleich SPARC- und x86-Hardware, und die Prozessnamen kthreadd und ksoftirqd stammen aus dem Linux-Kernel, nicht aus Solaris.
Warum verrät bin/history den Trick des Filmteams?
Ein echtes history zeigt sich selbst als letzten Eintrag der Liste, im Film fehlt dieser Eintrag. Tatham vermutet ein einfaches Skript, das den für die Handlung gewünschten Verlauf ausgibt. Mit einem Shell-Alias wäre der Trick unsichtbar geblieben.
Was bleibt an der Szene ungeklärt?
Ein Terminal-Fenster nutzt eine Proportionalschrift und bricht Zeilen am Wortende um wie ein Texteditor, während das top-Fenster daneben korrekt mit Festbreitenschrift arbeitet. Auch in seiner Analyse vom Mai 2026 fand Tatham für diesen Widerspruch keine Erklärung.
Mehr Newshunger?
