Warum gibt es sowohl die Umgebungsvariablen TMP als auch TEMP? (2015)

• Unter Windows existieren sowohl TMP als auch TEMP weiterhin als Angaben für den Speicherort temporärer Dateien, und wenn sie sich unterscheiden, hängt es von der Implementierung des Programms ab, welche verwendet wird
• CP/M hatte keine Umgebungsvariablen, daher musste der Speicherort für temporäre Dateien pro Programm festgelegt werden; Programme wie WordStar änderten ihr Verhalten, indem bestimmte Bytes in der ausführbaren Datei gepatcht wurden
• MS-DOS fügte unter starker Berücksichtigung der CP/M-Kompatibilität zwar Umgebungsvariablen hinzu, aber frühe MS-DOS-Programme verwendeten wegen der CP/M-Trägheit TEMP oder TMP kaum
• Als MS-DOS-Programme begannen, Umgebungsvariablen als Mittel zum Speichern von Einstellungen zu verwenden, konkurrierten TEMP und TMP miteinander, und einige Programme wie DISKCOPY und EDIT suchten TEMP vor TMP
• Die Pipe-Implementierung in MS-DOS 2.0 entschied sich für TEMP als Speicherort für temporäre Dateien, aber unter Windows prüft GetTempFileName zuerst TMP, wodurch beide Variablen weiter nebeneinander bestehen blieben

---

Der Hintergrund, warum TMP und TEMP beide geblieben sind

• In den Windows-Umgebungsvariablen existieren sowohl TMP als auch TEMP als Variablen zur Angabe des Speicherorts temporärer Dateien; wenn sie unterschiedlich sind, hängt es vom jeweiligen Programm ab, welche als korrekt angesehen wird
• Wo ein bestimmtes Programm seine temporären Dateien anlegt, hängt von dessen Implementierung ab; Windows-Programme verwenden wahrscheinlich die Funktion GetTempFileName, in diesem Fall hat TMP Vorrang
• Dass im Dialogfeld für Umgebungsvariablen sowohl TMP als auch TEMP angezeigt werden, liegt daran, dass sich historisch keine der beiden Optionen vollständig als Standard durchgesetzt hat und unterschiedliche Entscheidungen nebeneinander fortbestanden

CP/M hatte keine Umgebungsvariablen

• Um 1973 war CP/M ein auf Mikrocomputern verbreitetes Betriebssystem, und CP/M hatte keine Umgebungsvariablen
• Da es keine Umgebungsvariablen gab, existierten auch keine Umgebungsvariablen TMP oder TEMP
• Um in einem Programm den Speicherort für temporäre Dateien festzulegen, war eine programmspezifische Konfiguration nötig; typischerweise wurden bestimmte Bytes in der ausführbaren Datei gepatcht, um etwa den Laufwerksbuchstaben festzulegen, auf dem temporäre Dateien abgelegt werden sollten
• Programme wie WordStar dokumentierten im Handbuch, welche Bytes zu patchen waren, um welches Verhalten zu ändern, und boten sogar Patch-Bereiche für benutzerdefinierte Subroutinen etwa zur Druckerunterstützung

MS-DOS und das Aufkommen der Umgebungsvariablen

• 1981 erschienen der 8086-Prozessor und MS-DOS, die beide stark von CP/M beeinflusst waren
• Eines der frühen Designziele von MS-DOS war es, CP/M-Programme für den 8080-Prozessor maschinell in MS-DOS-Programme für den 8086-Prozessor übersetzen zu können
• Dieser Übersetzer setzte voraus, dass keine Sonderfälle wie selbstmodifizierender Code, Sprünge in die Mitte von Instruktionen oder die Verwendung von Code als Daten vorkamen
• Die Register H und L des 8080 entsprachen den Registern BH und BL des 8086, und weil im 8080 nur HL für berechnete Adresszugriffe verwendet werden konnte, durfte beim 8086 unter AX, BX, CX und DX nur BX für Speicherzugriffe verwendet werden
• Zusätzlich zur CP/M-Kompatibilität führte MS-DOS zwar Umgebungsvariablen ein, doch da bestehende CP/M-Programme keine Umgebungsvariablen verwendeten, nutzten auch frühe MS-DOS-Programme sie nicht
• Benutzer konnten zwar TEMP oder TMP setzen, aber frühe Programme ignorierten das weitgehend

TEMP und TMP konkurrierten auf dem Markt

• Mit der Zeit wurden Programme geschrieben, die primär auf MS-DOS zielten, und diese begannen, Umgebungsvariablen als Speicher für Konfigurationsdaten zu verwenden
• Als Umgebungsvariablen zur Angabe des Speicherorts temporärer Dateien kamen sowohl TEMP als auch TMP in Gebrauch, und beide wurden zu wichtigen Kandidaten
• Welche Variable zuerst geprüft wurde, hing von der Implementierungsentscheidung des jeweiligen Programms ab
• Viele Programme prüften beide, um möglichst viele Umgebungen abzudecken, aber die Reihenfolge unterschied sich je nach Implementierung
• Ältere Programme wie DISKCOPY und EDIT suchten TEMP vor TMP

Die Pipes von MS-DOS 2.0 und TEMP

• MS-DOS 2.0 führte die Pipe-Funktion ein, mit der die Ausgabe eines Programms an die Eingabe eines anderen Programms übergeben werden konnte
• Da MS-DOS ein Single-Tasking-Betriebssystem war, wurden Pipes simuliert, indem die Ausgabe des ersten Programms in eine temporäre Datei umgeleitet, dieses Programm vollständig ausgeführt und danach das zweite Programm mit dieser temporären Datei als Eingabe gestartet wurde
• Dadurch musste MS-DOS selbst einen Ort kennen, an dem temporäre Dateien angelegt werden konnten
• Als Variable zur Steuerung dieses Speicherorts wurde TEMP gewählt
• Auch wenn COMMAND.COM sich für TEMP entschied, blieb es anderen Programmen weiterhin selbst überlassen, ob sie TEMP oder TMP verwendeten

Unter Windows entstand ein Pfad mit Vorrang für TMP

• Windows durchlief einen ähnlichen Prozess, doch die frühe Implementierung von GetTempFileName wurde so gestaltet, dass sie TMP vor TEMP prüft
• Wenn ein Windows-Programm beim Erzeugen temporärer Dateien GetTempFileName verwendet, bevorzugt es daher eher TMP
• Deshalb gibt es auf die Frage, „welche Variable die richtige ist“, keine einzelne Antwort; es hängt davon ab, welche API oder welche eigene Logik ein Programm verwendet
• Auch heute sind im Dialogfeld für Umgebungsvariablen sowohl TMP als auch TEMP vorhanden, und beide Variablen bestehen für den Speicherort temporärer Dateien weiterhin nebeneinander

[GN⁺]

Hacker-News-Kommentare

• Interessant. Das liegt noch vor meiner Zeit, daher hatte ich nie davon gehört, dass man CP/M-Programme per Patch konfiguriert hat

  • Stimmt, das gab es tatsächlich, und der Patch-Code musste in Z80/8080-Maschinensprache geschrieben sein
    Mit dieser Funktion habe ich für mein WordStar selbst schnellere Routinen für Tastatur- und Bildschirmausgabe geschrieben
  • Ja, das gab es wirklich, und einige Programme, die ursprünglich CP/M-Programme waren, hielten sich noch bis WordStar 7.0 für DOS
    Soweit ich mich erinnere, enthielt die WordStar-7-Dokumentation Patch-Positionen, mit denen man das Programmverhalten über DOS-debug.exe ändern konnte
  • In gewissem Maß existiert das heute noch. Die Sachen von suckless werden meist durch Ändern von config.h und anschließendes Neukompilieren konfiguriert
    https://suckless.org/
    Nachtrag: Ich habe erst später gesehen, dass das in einem anderen Unterthread auf dieser Seite schon erwähnt wurde
  • Diese Vorgehensweise war nötig, weil RAM und Plattenspeicher extrem knapp waren und fast jeder Computer einen Assembler mitbrachte
    Viele CP/M-Programme mussten mit 32K RAM und langsamen 130K-Disketten laufen, im Extremfall sogar auf Kassetten. Wer 64K RAM und 360K Speicher hatte, war schon ziemlich privilegiert
    Damals optimierte man Programme, anders als heute, nicht für das obere Ende des Marktes, sondern für das untere. Je mehr Systeme unterstützt wurden, desto mehr konnte man verkaufen, ohne den Kunden ein Hardware-Upgrade aufzudrängen
    Für externe Konfigurationsdateien oder Programme zu deren Erstellung war schlicht kein Platz da, und selbst das Parsen von Kommandozeilenargumenten verbrauchte wertvolle Bytes
    Heute beklagt man sich darüber, dass ein MacBook Neo nur 8.000.000.000 Byte RAM habe, aber 1978 konnte man sogar eine IDE mit 2.048 Byte bauen

• Ich mag Raymonds Blog, aber die Behauptung, CP/M sei 1973 auf Mikrocomputern verbreitet gewesen, ist seltsam
  Die Mikrocomputer von 1973 waren eher Prototypen auf dem Niveau von Entwicklungssystemen wie dem Intel Intellec und hatten überhaupt kein Betriebssystem. Dass Kildall 1973 mit der Entwicklung von CP/M begann, stimmt zwar, aber damals lief es nur auf einem Simulator auf einem PDP-10-Mainframe
  1979 würde Sinn ergeben, aber 1973 ist viel zu früh

  • In Wikipedia steht, CP/M sei 1974 entwickelt worden, also ist die Zeitachse hier eindeutig verschoben
  • Lustig ist, dass der Abstand zwischen 1979 und 1973 so groß ist wie zwischen 2020 und heute
    Wenn man das so sieht, merkt man plötzlich, dass es 2020 noch kein ChatGPT gab

• Ein gutes Beispiel dafür, wie eine Entscheidung eines frühen Entwicklers, fast ohne Nachdenken getroffen, jahrzehntelang bestehen bleibt

  • Eine zentrale Tabelle in einem S&P500-Produkt, an dem ich kurz gearbeitet habe, wird wohl für immer attornies heißen. Am Anfang hat einfach niemand den Tippfehler bemerkt
  • Nichts ist so dauerhaft wie eine TMPoräre Entscheidung

• Dass Programme TMP gewählt haben, liegt wahrscheinlich daran, dass Dateierweiterungen unter MS-DOS höchstens drei Zeichen lang sein durften und man für temporäre Dateien üblicherweise die Erweiterung .TMP verwendete

• Ähnlich wie bei Unix-Programmen, die nicht konsistent darin waren, ob sie http_proxy oder HTTP_PROXY beachten
  Heute prüfen viele Programme beide, aber nicht unbedingt in derselben Reihenfolge

• Die Erwähnung von CP/M ist verwirrend. Der Autor sagt erst, es werde später wichtig, erklärt dann aber am Ende offenbar, dass es nichts mit CP/M oder der 8080-CPU zu tun hatte

  • Stimme zu. Diese Geschichte hat weder mit CP/M noch mit dem Nebenschauplatz 8080/8086 wirklich viel zu tun
    Der Kernpunkt ist nur, dass Microsoft es selbst verwendet hat, aber nie daran dachte, es zu standardisieren
  • Wenn CP/M Umgebungsvariablen für Konfiguration benutzt hätte, dann hätte es bereits einen Standard gegeben, ob man TMP oder TEMP verwendet, und DOS hätte sich daran orientiert
    Das eigentliche Hindernis war aber, dass CP/M keine Verzeichnisse hatte und DOS 1.0 ebenfalls nicht
  • Könntest du die Stelle zitieren, die du meinst?

• Um 1995 herum hatte Telstra, also Australia Telecom, unternehmensweit etwa 50.000 Desktop-Rechner
  Eines Tages tauchte im Netzwerk-Home-Verzeichnis aller ein kleines File namens null auf, und vermutlich hatte ein Unix-Benutzer versucht, eine .bat-Datei zu schreiben
  Das führt zurück zur Frage, warum man einem bestehenden Standard folgen sollte. Ich wollte schon fragen: „Warum standardisieren?“, dachte dann aber, das könnte Nordamerikaner verwirren

  • Vermutlich hat man zuerst /dev/null versucht, das hat nicht funktioniert, und dann einfach auf null gewechselt
    Sonst ergibt es keinen Sinn, dass es ein Unix-Programmierer gewesen sein soll. Eher hat ein DOS-Programmierer NUL fälschlich als null geschrieben
  • Ich frage mich, welcher Text eigentlich verworfen werden sollte
  • Ein Installationsprogramm für irgendeinen Logitech-Treiber hat einmal etwas Ähnliches gemacht
    Es suchte auf der Festplatte nach einer Datei namens NULL, und natürlich stand in der .BAT-Datei etwas wie > NULL

• Ehrlich gesagt wäre mir bei vielen Programmen die CP/M-artige Patch-Konfiguration lieber als die Praxis, Dotfiles im Home-Verzeichnis zu verstreuen

  • Wenn sich die Leute einfach an die XDG Base Directory Specification halten würden, wäre die Wildwuchs-Problematik bei Konfigurationsdateien kein großes Thema
    Immer mehr Projekte übernehmen das, sogar solche, die sich lange gesträubt haben, wie Firefox
  • Eine etwas eigenwillige Philosophie bei suckless ist, dass Projekte meist durch Ändern des Quellcodes und anschließendes Neukompilieren konfiguriert werden
    Aus moderner Open-Source-Sicht kann man das als ähnlichen Ansatz sehen. Wegen des allgemeinen Asketismus sind die Projekte aber wohl Geschmackssache
  • Eigentlich sollte alles in .config liegen
    Das Problem ist, dass viele App-Entwickler meinen, gerade ihre App sei so besonders, dass sie ein eigenes Verzeichnis verdiene
  • Ich finde Dotfiles, die man mit grep durchsuchen und mit einem Texteditor verwalten kann, besser als Konfigurationen, die über irgendeine zentrale binäre Registry verstreut sind
    Vielleicht liegt das auch einfach daran, dass ich daran gewöhnt bin
  • Ich wünschte, das wäre standardisiert. Wenn es eine Distribution gäbe, die einen .config-Ordner irgendwie erzwingen kann, wäre das für mich ein Gewinner
    Andererseits könnte der richtige Zeitpunkt dafür längst verpasst sein

• Ich wusste nicht, dass das so verwirrend ist
  Die Lehre daraus ist wohl: Lass immer beide auf denselben Pfad zeigen, sonst gibt es Ärger

• Ich weise seit Jahrzehnten auf solche nervigen Microsoft-Dinge hin
  Früher gab es dort immer einen „Senior Developer“, der so tat, als wüsste er alles, und für alles eine Antwort hatte. Dann hieß es etwa: „temp steht für temporary und tmp für troubleshoot my pc, das ist für Debug-Logs. Deshalb bin ich Senior und du nicht.“
  Als ich selbst seniorer wurde, stellte sich heraus, dass meine Zweifel berechtigt waren, und wenn man heute mit den ursprünglichen Microsoft-Entwicklern spricht, erklären sie, es sei ein Fehler gewesen, aber aus Gründen der Abwärtskompatibilität beibehalten worden
  Dann fragt man sich allerdings, warum diese Ausrede gültig sein soll, wenn man unter Berufung auf Abwärtskompatibilität argumentiert, aber gleichzeitig Änderungen wie bei New Outlook trotzdem durchdrückt, obwohl sie Kernkompatibilität und echte Arbeitsabläufe regelmäßig kaputtmachen. Dann ziehen sie sich darauf zurück: „Ich bin kein schlechter Entwickler, frag die Neuen“
  Die Neuen kann man aber gar nicht fragen, sie verstecken sich hinter LeetCode-Auswahlhürden. Deshalb werden solche realen Probleme nie behoben, und Dinge wie New Outlook entstehen überhaupt erst. Der damalige Senior Developer arbeitet jetzt wahrscheinlich dort, und die echten Entwickler sind in Rente
  Selbst wenn man von Microsoft eine halbwegs plausible Antwort darauf bekommt, warum irgendwelche Programme den Documents-Ordner des Benutzers unangemessen verwenden oder OneDrive ihn versehentlich zwangsweise leert, wird diese Kernlogik innerhalb von sechs Monaten wieder untergraben, weil Microsoft irgendeine zufällige Änderung einspielt, die das Verhalten in eine schlechtere Richtung verschiebt
  Bei Notepad ähnlich: In Entwicklerinterviews hieß es, das Risiko müsse null sein, deshalb müsse es ein extrem einfaches Programm bleiben, und später bekam es dann Microsoft-Konto-Anmeldung und Copilot
  Ich denke, diese LeetCode-Mentalität von Entwicklern und die Microsoft-Kultur ruinieren die ganze Branche. Eine sachliche Diskussion ist nicht möglich, stattdessen läuft es auf „Du arbeitest nicht bei Microsoft, also ist dein Argument ungültig“ hinaus
  Ich erinnere mich noch gut daran, wie Google Chrome nach AppData installiert wurde, um Administratorrechte zu umgehen. Offensichtlich war diese Funktion ursprünglich nicht dafür gedacht, dass Dritte ohne Administratorrechte Software installieren
  Aber Chrome war damals gut, und man musste irgendwie das Chaos bewältigen, Drittanbieter-Ausnahmen auf Millionen gesperrter Firmenrechner zu verteilen, also wird das von Entwicklern heute im Nachhinein als beabsichtigte Funktion umgedeutet