Simon Tatham hat Tron Legacy auf Pause gedrückt, das Terminal-Fenster studiert und daraus eine eintägige Unterrichtseinheit für einen Junior-Kollegen gemacht. Was dabei herauskam, ist eine der schärfsten Filmkritiken, die je jemand über 30 Zeilen Shell-History geschrieben hat.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Simon Tatham, Schöpfer von PuTTY, analysierte am 28. Mai 2026 die Terminal-Szene in Tron Legacy (2010) als Lernübung für einen Junior-Kollegen
- Das Shell-Transcript im Film ist überraschend gut konstruiert: Speicherfreigabe, Doppel-Sicherung am Laser-Controller, ein Backdoor-Account mit plausibler Erklärung
- Klare Fehler:
bin/historystatt des eingebautenhistory-Befehls verrät den Fake-Trick, und deruname-Output mischt SPARC- mit x86-Hardware - Ungeklärt bleibt das Proportionalschrift-Terminal mit Wortumbruch: Tatham hat nach 16 Jahren noch keine Erklärung dafür
Welche Unix-Details hat das Filmteam richtig hinbekommen?
Das Transcript beginnt mit whoami, landet bei einem fehlgeschlagenen Root-Login, wechselt dann zum backdoor-Account, der ebenfalls UID 0 hat. Das ist kein Zufallsrauschen. Jemand im Produktionsteam kannte Unix gut genug, um zu wissen, dass zwei Accounts dieselbe UID teilen können und damit dieselbe Shell-History lesen. Tatham hält die Version für plausibel, dass Sam Flynn den Backdoor selbst angelegt hatte, um seinen zunehmend geheimnistuenden Vater im Auge zu behalten.
Das ./configure -o test.cfg im History-Log ist kein Autoconf-Aufruf, sondern ein eigenes Konfigurationsskript des Laser-Controllers. Das -o-Flag macht das deutlich: Autoconf-Scripts kennen diesen Parameter nicht. Tatham hatte das beim ersten Ansehen für einen Fehler gehalten, revidierte sein Urteil bei der Analyse mit dem Kollegen.
Auch der Doppel-Sicherheitsmechanismus des Laser-Controllers überzeugt: erst ein touch /opt/LLL/run/ok, das eine leere Datei als Freigabe anlegt, dann der explizite -ok 1-Parameter beim Aufruf. Beide Techniken stammen aus echter Unix-Software. Git verwendet dasselbe Muster: git-daemon verlangt eine git-daemon-export-ok-Datei im Repository, git-clean löscht nur mit explizitem -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-Builtins history. Shell-History lebt in der laufenden Shell-Instanz, kein externes Kommando kommt dort heran. Tatham vermutet, dass das Produktionsteam ein einfaches Shell-Script namens bin/history verwendet hat, das die gewünschte, plot-relevante History ausgibt, während das echte System eine andere Vergangenheit hatte.
Das Script hat sich selbst verraten, weil der letzte Eintrag nicht der gerade ausgeführte Befehl ist: Ein echtes history würde sich selbst am Ende der Liste zeigen. Hätte das Team stattdessen ein Shell-Alias definiert, wäre der Trick unsichtbar geblieben.
Der uname -a-Output nennt sowohl sun4m als auch i386. Das ist physikalisch unvereinbar: sun4m bezeichnet SPARC-Hardware, i386 x86. Ein echter Solaris-Rechner auf x86 hätte i86pc ausgegeben. Dazu kommen die Prozessnamen in der linken Terminal-Spalte, etwa kthreadd und ksoftirqd: Das sind Linux-Kernel-Threads, kein Solaris.
Das Produktionsteam arbeitete augenscheinlich auf einem echten Linux-Rechner, dekorierte die uname-Ausgabe manuell zu einem fiktiven SolarOS um und ließ dabei vergessen, dass die anderen Fenster dieselbe Maschine zeigen.
Beim Lesen der History auf drweb.de fällt auf, wie stark praktisches Lesen von Code und Systembefehlen das Programmierverständnis schärft: Egal ob Python, Rust oder klassisches C wie in PuTTY, wer Transkripte und Logs entschlüsseln kann, gewinnt Tiefe.
Was bleibt nach 16 Jahren ungeklärt?
Das Terminal-Fenster im Hauptbild verwendet Proportionalschrift statt Festbreitenfont und bricht Zeilen am Wortende um, wie ein Texteditor das täte. In einem normalen Terminal läuft der Zeilenbruch hart am Rand. Tatham hat keine Erklärung dafür, weder absichtlich noch versehentlich. Das top-Fenster links im gleichen Screenshot verhält sich dagegen korrekt mit Festbreitenfont. Die drei Terminal-Fenster sind also nicht konsistent.
Auch der letzte Wille in ~/last_will_and_testament.txt wirft Fragen auf. Flynn schreibt das Testament in das Home-Verzeichnis von Root, das laut System auf / liegt. Ohne Zeugen und Unterschrift hat das Dokument keine rechtliche Wirkung. Tatham kommentiert trocken: Wer kurz davor steht, sich selbst mit einem Laser zu digitalisieren, denkt wahrscheinlich nicht mehr ganz klar.
Die komplette Analyse steht auf Tathams persönlicher Site und eignet sich als Lektüre für alle, die Unix nicht nur nutzen, sondern verstehen wollen. Ähnlich strukturiertes Denken zahlt sich aus, wenn Sie etwa in einem HTML-Editor unerwartetes Verhalten debuggen oder auf Linux-Servern mit SSH-Clients wie PuTTY arbeiten.
Für Entwickler, die auf Windows-Maschinen mit Unix-Tools arbeiten, ist die Analyse auch ein Reminder: Die Windows-Entwicklungsumgebung 2025 bringt WSL und ein richtiges Terminal mit. Shell-Literacy bleibt auch 2026 ein Handwerk, das keine KI vollständig ersetzt.
