¿Por qué existen tanto las variables de entorno TMP como TEMP? (2015)

• En Windows todavía existen tanto TMP como TEMP para indicar la ubicación de archivos temporales, y cuando difieren, cuál se usa depende de la implementación de cada programa
• CP/M no tenía variables de entorno, así que la ubicación de los archivos temporales debía configurarse por programa, y aplicaciones como WordStar usaban un método de parchear bytes específicos del ejecutable para cambiar el comportamiento
• MS-DOS añadió variables de entorno teniendo muy presente la compatibilidad con CP/M, pero los primeros programas de MS-DOS casi no usaban TEMP ni TMP por la inercia heredada de CP/M
• A medida que los programas de MS-DOS empezaron a usar variables de entorno para guardar configuración, TEMP y TMP compitieron entre sí, y algunos programas como DISKCOPY y EDIT buscaban TEMP antes que TMP
• La implementación de pipes en MS-DOS 2.0 eligió TEMP para la ubicación de archivos temporales, pero GetTempFileName en Windows revisa primero TMP, lo que hizo que ambas variables siguieran coexistiendo

---

El trasfondo de por qué sobrevivieron tanto TMP como TEMP

• En las variables de entorno de Windows existen tanto TMP como TEMP para indicar la ubicación de archivos temporales, y si ambas difieren, cuál es la correcta depende de cada programa
• El lugar donde un programa crea archivos temporales depende de su implementación; en Windows, es probable que un programa use la función GetTempFileName, y en ese caso TMP tiene prioridad
• La razón por la que TMP y TEMP aparecen juntas en el cuadro de diálogo de variables de entorno es que ninguna quedó totalmente estandarizada, y por razones históricas convivieron elecciones distintas

CP/M no tenía variables de entorno

• Hacia 1973, el sistema operativo común en las microcomputadoras era CP/M, y CP/M no tenía variables de entorno
• Como no había variables de entorno, tampoco existían las variables TMP ni TEMP
• Para indicar en un programa dónde guardar archivos temporales, había que configurarlo por separado para cada aplicación; por ejemplo, se parcheaban bytes específicos del ejecutable para indicar la letra de unidad donde se colocarían los archivos temporales
• Programas como WordStar incluían en el manual qué byte había que parchear para cambiar cada comportamiento, y también ofrecían espacio de parche para insertar subrutinas personalizadas, como soporte para impresoras

La llegada de MS-DOS y las variables de entorno

• En 1981 aparecieron el procesador 8086 y MS-DOS, ambos fuertemente influenciados por CP/M
• Uno de los objetivos de diseño iniciales de MS-DOS era permitir traducir mecánicamente programas de CP/M para procesadores 8080 a programas de MS-DOS para procesadores 8086
• Ese traductor asumía que no se usaban rarezas como código automodificable, saltos al medio de instrucciones o el uso del código como datos
• Los registros H y L del 8080 correspondían a los registros BH y BL del 8086, y el hecho de que en el 8080 solo HL pudiera usarse para acceder a direcciones calculadas ayudó a explicar por qué en el 8086, entre AX, BX, CX y DX, solo BX podía usarse para acceso a memoria
• Además de la compatibilidad con CP/M, MS-DOS añadió variables de entorno, pero como los programas heredados de CP/M no las usaban, los primeros programas de MS-DOS tampoco las aprovecharon
• Los usuarios podían definir TEMP o TMP, pero los programas iniciales no les prestaban atención

TEMP y TMP compitieron en el mercado

• Con el tiempo, a medida que se escribían programas pensados principalmente para MS-DOS, estos comenzaron a usar variables de entorno como medio para almacenar configuración
• TEMP y TMP empezaron a usarse como variables de entorno para indicar la ubicación de archivos temporales, y ambas surgieron como candidatas principales
• Qué variable revisar primero dependía de la decisión de implementación de cada programa
• Muchos programas comprobaban ambas para satisfacer a todos, pero el orden de prioridad variaba según la implementación
• Programas antiguos como DISKCOPY y EDIT buscaban TEMP antes que TMP

Los pipes de MS-DOS 2.0 y TEMP

• MS-DOS 2.0 introdujo la función de pipes para pasar la salida de un programa a la entrada de otro
• Como MS-DOS era un sistema operativo de una sola tarea, los pipes se simulaban redirigiendo la salida del primer programa a un archivo temporal, ejecutándolo hasta el final, y luego ejecutando el segundo programa tomando como entrada ese archivo temporal
• Debido a esto, MS-DOS mismo necesitó una ubicación donde crear archivos temporales
• La variable elegida para controlar esa ubicación fue TEMP
• Aunque COMMAND.COM eligiera TEMP, seguía siendo decisión de cada programa usar TEMP o TMP

En Windows surgió una ruta donde TMP tiene prioridad

• Windows pasó por un proceso similar, pero la implementación inicial de GetTempFileName se hizo para revisar TMP antes que TEMP
• Cuando un programa de Windows usa GetTempFileName para crear archivos temporales, tiende a preferir TMP
• Por eso no existe una única respuesta a la pregunta de “cuál variable es la correcta”; depende de qué API o lógica propia use el programa
• Incluso hoy, en el cuadro de diálogo de variables de entorno siguen apareciendo tanto TMP como TEMP, y ambas variables continúan coexistiendo para la ubicación de archivos temporales

[GN⁺]

Comentarios de Hacker News

• Qué interesante. Nunca había oído que en mi época anterior se configuraran programas de CP/M con parches

  • Sí, de verdad se hacía así, y el código del parche tenía que estar en lenguaje máquina Z80/8080
    Con esa función escribí yo mismo rutinas más rápidas de teclado y salida de pantalla para mi WordStar
  • Sí, realmente existía, y algunos programas que originalmente eran de CP/M siguieron así hasta WordStar 7.0 para DOS
    Recuerdo que la documentación de WordStar 7 incluía ubicaciones de parches que se podían usar con debug.exe de DOS para cambiar el comportamiento del programa
  • En cierto grado todavía queda algo de eso. Las cosas que hace suckless normalmente se configuran cambiando config.h y recompilando
    https://suckless.org/
    Agrego que vi tarde que esto ya se había mencionado en otro subhilo de esta página
  • Ese enfoque era necesario porque la RAM y el espacio en disco estaban extremadamente limitados, y casi todas las computadoras venían con ensamblador
    Muchos programas de CP/M tenían que correr con 32K de RAM y disquetes lentos de 130K, o incluso en casete en el peor de los casos. Tener 64K de RAM y discos de 360K ya te ponía en una categoría bastante especial
    En esa época, a diferencia de hoy, los programas no se optimizaban para el extremo alto del mercado sino para el bajo. Cuantos más sistemas pudieran ejecutarlos, más se vendían, y no se le cargaba al cliente la responsabilidad de actualizar el hardware
    Simplemente no había espacio para archivos de configuración externos ni para programas que generaran esos archivos, e incluso procesar argumentos de línea de comandos consumía bytes valiosos
    Hoy la gente se queja de que una MacBook Neo solo tiene 8,000,000,000 bytes de RAM, pero en 1978 se podía hacer hasta un IDE básico de 2,048 bytes

• Me gusta el blog de Raymond, pero suena raro decir que CP/M era común en microcomputadoras en 1973
  Las microcomputadoras de 1973 eran más bien prototipos al nivel de sistemas de desarrollo como el Intel Intellec, y ni siquiera tenían sistema operativo. Es cierto que Kildall empezó a desarrollar CP/M en 1973, pero en ese momento solo corría en un simulador en un mainframe PDP-10
  En 1979 sí, pero 1973 es demasiado temprano

  • En Wikipedia dice que CP/M se creó en 1974, así que la cronología aquí claramente no cuadra
  • Da risa pensar que la diferencia entre 1979 y 1973 es la misma que entre 2020 y hoy
    Viéndolo así, uno piensa que en 2020 no existía ChatGPT

• Un buen ejemplo de cómo una decisión que un desarrollador inicial tomó casi sin pensarlo permanece durante décadas

  • Una de las tablas centrales de un producto del S&P500 con el que trabajé un rato probablemente se llamará attornies para siempre, porque nadie detectó el error al principio
  • No hay nada más permanente que una decisión TMPoraria

• Es muy probable que los programas eligieran TMP porque en MS-DOS las extensiones de archivo tenían un máximo de 3 caracteres, y existía la costumbre de usar la extensión .TMP para archivos temporales

• Se parece a la falta de consistencia sobre si los programas de Unix revisaban http_proxy o HTTP_PROXY
  Hoy muchos programas revisan ambos, pero el orden de comprobación puede no ser el mismo

• La mención de CP/M confunde. El autor parece decir que después sería importante, pero al final explica que no tenía relación con CP/M ni con la CPU 8080

  • De acuerdo. Esta historia en realidad no tiene mucho que ver ni con CP/M ni con la tangente hacia 8080/8086
    El punto central es solo que Microsoft lo usaba internamente y nunca pensó en estandarizarlo
  • Si CP/M hubiera usado variables de entorno para configuración, ya habría existido un estándar sobre si usar TMP o TEMP, y DOS lo habría seguido
    Pero el verdadero obstáculo es que CP/M no tenía directorios, y DOS 1.0 tampoco
  • ¿Podrías citar a qué frase te refieres?

• Hacia 1995, Telstra, es decir Australia Telecom, tenía unas 50 mil computadoras de escritorio en toda la organización
  Un día apareció un pequeño archivo llamado null en el directorio home de red de todo el mundo, y al parecer algún usuario de Unix intentó escribir un archivo .bat
  Todo esto para decir: ¿por qué habría que seguir un estándar ya existente? Quise preguntar “¿por qué hay que estandarizar?”, pero pensé que quizá eso podría confundir a la gente de Norteamérica

  • Probablemente primero intentaron /dev/null, falló, y entonces lo cambiaron simplemente a null
    Si no fue así, no tiene mucho sentido que lo haya hecho un programador de Unix. Más bien parece que un programador de DOS escribió mal NUL como null
  • Me da curiosidad saber cuál era el texto que intentaban descartar
  • Un instalador de controladores de Logitech también hizo algo parecido
    Encontró un archivo llamado NULL en el disco duro, y por supuesto dentro del archivo .BAT había algo como > NULL

• Si soy sincero, en muchos programas la configuración estilo parche de CP/M me parece mejor que regar dotfiles por todo el directorio home

  • Si la gente simplemente siguiera la XDG Base Directory Specification, la proliferación de archivos de configuración no sería un problema
    Cada vez más proyectos la adoptan, incluso algunos tan reacios como Firefox
  • Una de las filosofías algo peculiares del lado de suckless es que los proyectos se configuran, en general, modificando el código fuente y recompilando
    Visto desde el open source moderno, podría decirse que es un enfoque parecido. Aunque por su ascetismo general, da la impresión de que esos proyectos son cuestión de gustos
  • Originalmente todo debería ir dentro de .config
    El problema es que muchos desarrolladores de apps creen que su app es tan especial que merece tener un directorio propio
  • Aun así, prefiero los dotfiles que puedes grepear y gestionar con un editor de texto antes que configuraciones dispersas por todo un registro binario central
    Aunque tal vez sea solo costumbre
  • Ojalá esto estuviera estandarizado. Si existiera una distro que de algún modo pudiera imponer la carpeta .config, para mí sería la ganadora
    Aunque quizá ya se perdió el momento para hacerlo

• No sabía que esto fuera tan confuso
  La lección probablemente sea hacer que siempre apunten a la misma ruta, o si no, se arma un desastre

• Llevo décadas señalando estas cosas irritantes de Microsoft
  Antes siempre había algún “desarrollador senior” ahí que parecía tener todas las respuestas. Algo como: “temp es temporary y tmp es troubleshoot my pc, para logs de depuración. Por eso yo soy senior y tú no”
  Cuando me volví más senior, vi que tenía razón al cuestionarlo, y ahora cuando hablo con los desarrolladores originales de Microsoft me explican que fue un error, pero se mantuvo por compatibilidad hacia atrás
  Pero entonces me pregunto por qué esa excusa sí vale, cuando al mismo tiempo siguen empujando cambios que rompen compatibilidad clave y flujos de trabajo reales, como New Outlook. Entonces salen con “yo no soy un mal desarrollador, pregúntales a los nuevos”
  A los nuevos ni se les puede preguntar, y además están escondidos detrás de la barrera de selección tipo LeetCode. Así que no sorprende que estos problemas reales no se arreglen y que salgan cosas como New Outlook. Ese senior de antes ahora trabaja ahí, y los desarrolladores de verdad ya se jubilaron
  Incluso cuando uno recibe de Microsoft una respuesta aparentemente razonable sobre problemas como programas aleatorios usando de forma inapropiada la carpeta Documents del usuario o OneDrive borrándola por error a la fuerza, en menos de 6 meses Microsoft mete un cambio aleatorio que empeora el comportamiento y destruye toda esa lógica central
  Con Notepad pasa algo parecido. En entrevistas a desarrolladores decían que debía ser un programa muy simple porque el riesgo tenía que ser cero, y luego le agregaron inicio de sesión con cuenta de Microsoft y Copilot
  Creo que la actitud de desarrollador estilo LeetCode y la cultura de Microsoft han arruinado a toda la industria. No se puede tener una discusión tranquila; todo termina en “tú no trabajas en Microsoft, así que tu argumento no vale”
  Recuerdo claramente cuando Google Chrome se instalaba en AppData para saltarse los privilegios de administrador. Claramente la intención original de esa función no era que terceros la usaran para instalar sin permisos de administrador
  Pero como Chrome era bueno en ese momento y había que lidiar con el caos de distribuir programas de excepción de terceros en millones de computadoras corporativas bloqueadas, ahora los desarrolladores lo están reempaquetando como si hubiera sido una función intencional