Por que as variáveis de ambiente TMP e TEMP existem ao mesmo tempo? (2015)

• No Windows, ainda existem tanto TMP quanto TEMP para indicar a localização de arquivos temporários, e quando os dois são diferentes, qual deles é usado depende da implementação do programa
• O CP/M não tinha variáveis de ambiente, então a localização dos arquivos temporários precisava ser configurada por programa, e softwares como o WordStar mudavam o comportamento aplicando patch em bytes específicos do executável
• O MS-DOS foi criado com forte preocupação com a compatibilidade com o CP/M e também adicionou variáveis de ambiente, mas os primeiros programas de MS-DOS quase não usavam TEMP ou TMP por inércia herdada do CP/M
• À medida que programas de MS-DOS passaram a usar variáveis de ambiente para armazenar configurações, TEMP e TMP passaram a competir, e alguns programas como DISKCOPY e EDIT procuravam TEMP antes de TMP
• A implementação de pipes no MS-DOS 2.0 escolheu TEMP para a localização de arquivos temporários, mas o GetTempFileName do Windows verifica TMP primeiro, fazendo com que as duas variáveis continuem coexistindo

---

O contexto de por que TMP e TEMP continuam existindo

• Nas variáveis de ambiente do Windows, existem tanto TMP quanto TEMP para definir a localização de arquivos temporários, e se os dois forem diferentes, qual deles está “certo” varia de programa para programa
• O local onde um programa específico cria arquivos temporários depende da implementação desse programa; programas Windows provavelmente usam a função GetTempFileName, e nesse caso TMP tem prioridade
• O motivo de TMP e TEMP aparecerem juntos na caixa de diálogo de variáveis de ambiente é que nenhum dos dois foi totalmente consolidado como padrão, e historicamente escolhas diferentes continuaram coexistindo

O CP/M não tinha variáveis de ambiente

• Por volta de 1973, o sistema operacional comum em microcomputadores era o CP/M, e o CP/M não tinha variáveis de ambiente
• Como não havia variáveis de ambiente, também não existiam as variáveis TMP ou TEMP
• Para definir onde salvar arquivos temporários em um programa, era preciso configurar isso individualmente, por exemplo aplicando patch em bytes específicos do executável para indicar a letra da unidade onde os arquivos temporários seriam colocados
• Programas como o WordStar traziam no manual quais bytes precisavam ser alterados para mudar determinado comportamento, e também ofereciam espaço de patch para incluir sub-rotinas personalizadas, como suporte a impressora

O surgimento do MS-DOS e das variáveis de ambiente

• Em 1981 surgiram o processador 8086 e o MS-DOS, ambos fortemente influenciados pelo CP/M
• Um dos objetivos iniciais de projeto do MS-DOS era permitir a tradução mecânica de programas CP/M para processador 8080 em programas MS-DOS para processador 8086
• Esse tradutor partia do pressuposto de que não seriam usados truques fora do padrão, como código auto-modificável, saltos para o meio de instruções ou uso de código como dados
• Os registradores H e L do 8080 correspondiam aos registradores BH e BL do 8086, e o fato de no 8080 apenas o registrador HL poder ser usado para acesso a endereços calculados ajudou a explicar por que, no 8086, entre AX, BX, CX e DX, só BX podia ser usado para acesso à memória
• Além da compatibilidade com CP/M, o MS-DOS adicionou variáveis de ambiente, mas como os programas CP/M existentes não as usavam, os primeiros programas de MS-DOS também não usavam variáveis de ambiente
• O usuário podia definir TEMP ou TMP, mas os programas iniciais simplesmente não davam atenção a isso

TEMP e TMP passaram a competir no mercado

• Com o tempo, começaram a surgir programas voltados principalmente para MS-DOS, e eles passaram a usar variáveis de ambiente como forma de armazenar dados de configuração
• TEMP e TMP começaram então a ser usados como variáveis de ambiente para indicar a localização de arquivos temporários, e ambos surgiram como principais candidatos
• Qual variável verificar primeiro dependia da escolha de implementação de cada programa
• Muitos programas verificavam as duas para atender aos dois casos, mas a ordem de prioridade variava conforme a implementação
• Programas antigos como DISKCOPY e EDIT procuravam TEMP antes de TMP

Os pipes do MS-DOS 2.0 e TEMP

• O MS-DOS 2.0 introduziu o recurso de pipe, que permite passar a saída de um programa para a entrada de outro
• Como o MS-DOS era um sistema operacional monotarefa, ele simulava pipes redirecionando a saída do primeiro programa para um arquivo temporário, executando-o até o fim e depois rodando o segundo programa para ler desse arquivo temporário
• Por causa desse recurso, o próprio MS-DOS passou a precisar de um local para criar arquivos temporários
• A variável escolhida para controlar esse local foi TEMP
• Mesmo que o COMMAND.COM tenha escolhido TEMP, continuava sendo decisão de cada programa usar TEMP ou TMP

No Windows surgiu um caminho em que TMP tem prioridade

• O Windows passou por processo parecido, mas a implementação inicial de GetTempFileName foi criada para verificar TMP antes de TEMP
• Quando um programa Windows usa GetTempFileName para criar arquivos temporários, ele tende a preferir TMP
• Portanto, não existe uma resposta única para “qual variável está certa”; isso depende de qual API ou lógica própria o programa usa
• Até hoje, a caixa de diálogo de variáveis de ambiente continua mostrando tanto TMP quanto TEMP, e as duas variáveis seguem coexistindo na definição da localização de arquivos temporários

[GN⁺]

Comentários do Hacker News

• Interessante. É de antes da minha época, então eu nunca tinha ouvido falar de configurar programas de CP/M por patch

  • Sim, isso realmente existia, e o código do patch precisava ser em linguagem de máquina Z80/8080
    Usei esse recurso para escrever eu mesmo rotinas mais rápidas de teclado e saída de tela no meu WordStar
  • Sim, isso realmente existia, e alguns programas que originalmente eram de CP/M continuaram por muito tempo, até o WordStar 7.0 para DOS
    Lembro que a documentação do WordStar 7 incluía posições de patch que podiam ser usadas com o debug.exe do DOS para mudar o comportamento do programa
  • Isso ainda sobrevive até certo ponto. As coisas feitas pela suckless geralmente são configuradas alterando o config.h e recompilando
    https://suckless.org/
    Aliás, só depois percebi que isso já tinha sido mencionado em outra subthread desta página
  • Esse método era necessário porque RAM e espaço em disco eram extremamente limitados, e quase todo computador vinha com um assembler
    Muitos programas de CP/M precisavam rodar com 32K de RAM e disquetes lentos de 130K, ou até em fita cassete nos casos piores. Ter 64K de RAM e disco de 360K já era algo bem especial
    Naquela época, ao contrário de hoje, os programas eram otimizados para a base do mercado, não para o topo. Quanto mais sistemas suportassem, mais vendiam, e não empurravam para o cliente a obrigação de fazer upgrade de hardware
    Simplesmente não havia espaço para arquivos de configuração externos nem para um programa que criasse esses arquivos, e até processar argumentos de linha de comando consumia bytes preciosos
    Hoje em dia o pessoal reclama que um MacBook Neo tem só 8.000.000.000 bytes de RAM, mas em 1978 já dava para fazer uma IDE básica de 2.048 bytes

• Gosto do blog do Raymond, mas dizer que CP/M era comum em microcomputadores em 1973 soa estranho
  Os microcomputadores de 1973 eram mais protótipos no nível de sistemas de desenvolvimento como o Intel Intellec, e nem tinham sistema operacional. É verdade que o Kildall começou a desenvolver o CP/M em 1973, mas naquela época ele só rodava em um simulador num mainframe PDP-10
  Em 1979 tudo bem, mas 1973 é cedo demais

  • A Wikipedia diz que o CP/M foi criado em 1974, então a cronologia aqui realmente parece errada
  • É engraçado pensar que a diferença entre 1979 e 1973 é a mesma que entre 2020 e hoje
    Aí você percebe que em 2020 ainda não existia ChatGPT

• Um bom exemplo de como uma decisão tomada por um desenvolvedor no começo, quase sem pensar, pode perdurar por décadas

  • Uma tabela central de um produto do S&P500 com a qual trabalhei brevemente provavelmente vai se chamar attornies para sempre, porque ninguém percebeu o erro no início
  • Não existe nada mais permanente do que uma decisão TMPorária

• É bem provável que os programas tenham escolhido TMP por causa da limitação de 3 caracteres nas extensões de arquivo do MS-DOS e da convenção de usar a extensão .TMP em nomes de arquivos temporários

• Parece o caso dos programas Unix que nunca foram consistentes sobre olhar http_proxy ou HTTP_PROXY
  Hoje muitos programas verificam ambos, mas a ordem de verificação pode não ser a mesma

• A referência a CP/M me confundiu. O autor parece dizer que isso seria importante depois, mas no fim explica que não tinha relação com CP/M nem com a CPU 8080

  • Concordo. Essa história não tem muita relação nem com CP/M nem com essa tangente sobre 8080/8086
    O ponto central é só que a Microsoft usava isso internamente e não pensou em padronizar
  • Se o CP/M usasse variáveis de ambiente para configuração, já teria surgido um padrão sobre usar TMP ou TEMP, e o DOS teria seguido isso
    Só que o verdadeiro obstáculo é que o CP/M não tinha diretórios, e o DOS 1.0 também não
  • Você pode citar a frase exata a que está se referindo?

• Por volta de 1995, a Telstra, ou Australia Telecom, tinha algo como 50 mil desktops na organização inteira
  Um dia, apareceu um pequeno arquivo chamado null no diretório home de rede de todo mundo, e aparentemente um usuário de Unix tinha tentado escrever um arquivo .bat
  É disso que se trata não seguir um padrão que já existe. Eu queria perguntar “por que padronizar?”, mas achei que isso talvez confundisse os norte-americanos

  • Provavelmente tentaram /dev/null primeiro, falhou, e aí trocaram só para null
    Caso contrário, não faz sentido culpar um programador Unix. Seria mais provável um programador DOS ter escrito null por engano no lugar de NUL
  • Fico curioso sobre qual texto eles estavam tentando descartar
  • Algum instalador de driver da Logitech fez algo parecido
    Procurava um arquivo chamado NULL no disco rígido e, claro, havia algo como > NULL dentro de um arquivo .BAT

• Sinceramente, acho que em muitos programas a configuração por patch no estilo CP/M teria sido melhor do que espalhar dotfiles pelo diretório home

  • Se as pessoas simplesmente seguissem a XDG Base Directory Specification, a proliferação de arquivos de configuração não seria um problema
    Cada vez mais projetos estão adotando isso, inclusive alguns que resistiam, como o Firefox
  • Uma das filosofias um pouco peculiares do pessoal do suckless é que os projetos em geral são configurados alterando o código-fonte e recompilando
    Dá para dizer que é uma abordagem parecida em termos modernos de open source. Só que, pelo ascetismo geral, os projetos provavelmente agradam mais a certos gostos do que a outros
  • Originalmente, tudo deveria ficar dentro de .config
    O problema é que muitos desenvolvedores de apps acham que o app deles é especial o bastante para merecer um diretório separado
  • Ainda prefiro dotfiles que você pode vasculhar com grep e editar com um editor de texto a configurações espalhadas por um registro binário central
    Talvez seja só costume
  • Eu gostaria que isso fosse padronizado. Se existir alguma distro que consiga impor de algum jeito a pasta .config, para mim já é vencedora
    Embora talvez já tenhamos perdido o timing para isso

• Eu não fazia ideia de que isso era tão confuso assim
  A lição provavelmente é: faça tudo apontar sempre para o mesmo caminho, ou vai dar problema

• Venho apontando essas coisas irritantes da Microsoft há décadas
  Antigamente sempre havia algum “desenvolvedor sênior” de lá que parecia saber tudo e tinha a resposta pronta. Era aquele tipo de coisa: “temp é temporary e tmp é troubleshoot my pc, usado para logs de depuração. Por isso eu sou sênior e você não”
  Quando fiquei mais sênior, percebi que eu estava certo em questionar, e agora, falando com os desenvolvedores originais da Microsoft, eles explicam que foi um erro, mas foi mantido por compatibilidade retroativa
  Só que aí eu pergunto por que essa desculpa valeria, se ao mesmo tempo eles continuam empurrando mudanças que quebram compatibilidade essencial e fluxos reais de trabalho, como aconteceu com o New Outlook. Aí vem a resposta padrão de “eu não sou um mau desenvolvedor, pergunte para o pessoal novo”
  Só que nem dá para perguntar para o pessoal novo, porque eles estão escondidos atrás da barreira de seleção estilo LeetCode. Então não é surpresa que esses problemas reais nunca sejam corrigidos e que coisas como o New Outlook acabem surgindo. Aquele desenvolvedor sênior de antes agora trabalha lá, e os desenvolvedores de verdade já se aposentaram
  Mesmo quando a Microsoft dá uma resposta aparentemente razoável sobre o uso indevido da pasta Documents do usuário por programas aleatórios, ou sobre o OneDrive apagá-la à força por engano, em menos de 6 meses a empresa empurra alguma mudança aleatória que piora o comportamento e destrói toda a lógica central da explicação
  O Notepad é parecido. Em entrevistas com desenvolvedores, diziam que ele precisava ser um programa extremamente simples porque o risco tinha de ser zero, e depois acabaram colocando login de conta Microsoft e Copilot nele
  Acho que essa mentalidade de desenvolvedor estilo LeetCode, junto com a cultura da Microsoft, estragou a indústria inteira. Não dá para ter uma discussão tranquila; tudo vira “você não trabalha na Microsoft, então seu argumento não vale”
  Também lembro bem de quando o Google Chrome era instalado em AppData para contornar privilégios de administrador. Claramente a intenção original desse recurso não era permitir que terceiros instalassem coisas sem privilégios de administrador
  Mas, como o Chrome era bom na época e alguém precisava lidar com a confusão de distribuir programas de exceção de terceiros para milhões de computadores corporativos bloqueados, os desenvolvedores agora tentam reembalar isso como se fosse funcionalidade intencional