▲

왜 TMP와 TEMP 환경 변수가 둘 다 있을까? (2015)

 (devblogs.microsoft.com)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • Windows에는 임시 파일 위치를 나타내는 TMP 와 TEMP 가 모두 남아 있으며, 둘이 다를 때 어느 쪽이 쓰이는지는 프로그램 구현에 따라 달라짐
  • CP/M에는 환경 변수가 없어서 임시 파일 위치를 프로그램별로 설정해야 했고, WordStar 같은 프로그램은 실행 파일의 특정 바이트를 패치해 동작을 바꾸는 방식을 사용함
  • MS-DOS는 CP/M 호환성을 강하게 의식하면서도 환경 변수를 추가했지만, 초기 MS-DOS 프로그램들은 기존 CP/M 관성 때문에 TEMP나 TMP를 거의 사용하지 않음
  • MS-DOS 프로그램들이 환경 변수를 설정 저장 수단으로 쓰기 시작하면서 TEMP와 TMP가 경쟁했고, DISKCOPY와 EDIT 같은 일부 프로그램은 TMP보다 TEMP를 먼저 찾았음
  • MS-DOS 2.0의 파이프 구현은 임시 파일 위치로 TEMP를 선택했지만, Windows의 GetTempFileName 은 TMP를 먼저 확인해 두 변수가 계속 공존하게 됨

TMP와 TEMP가 둘 다 남은 배경

  • Windows 환경 변수에는 임시 파일 위치를 지정하는 변수로 TMP와 TEMP가 모두 존재하며, 둘이 서로 다를 경우 어느 쪽이 맞는지는 프로그램마다 달라짐
  • 특정 프로그램이 임시 파일을 어디에 만들지는 그 프로그램의 구현에 달려 있으며, Windows 프로그램은 GetTempFileName 함수를 사용할 가능성이 높고 이 경우 TMP가 우선됨
  • 환경 변수 설정 대화상자에 TMP와 TEMP가 함께 보이는 이유는 한쪽이 표준으로 완전히 정리되지 않고, 역사적으로 서로 다른 선택이 공존했기 때문임

CP/M에는 환경 변수가 없었음

  • 1973년 무렵 마이크로컴퓨터에서 흔하던 운영체제는 CP/M이었고, CP/M에는 환경 변수가 없었음
  • 환경 변수가 없었기 때문에 TMP나 TEMP 환경 변수도 존재하지 않았음
  • 프로그램에 임시 파일 저장 위치를 지정하려면 프로그램별 설정이 필요했으며, 실행 파일의 특정 바이트를 패치해 임시 파일을 둘 드라이브 문자를 지정하는 식이었음
  • WordStar 같은 프로그램은 매뉴얼에 어떤 바이트를 패치하면 어떤 동작이 바뀌는지 담아뒀고, 프린터 지원 같은 커스텀 서브루틴을 넣을 수 있는 패치 공간도 제공함

MS-DOS와 환경 변수의 등장

  • 1981년에 8086 프로세서와 MS-DOS가 등장했으며, 둘 다 CP/M의 영향을 강하게 받음
  • MS-DOS의 초기 설계 목표 중 하나는 8080 프로세서용 CP/M 프로그램을 8086 프로세서용 MS-DOS 프로그램으로 기계 번역할 수 있게 하는 것이었음
  • 이 번역기는 자기 수정 코드, 명령어 중간으로의 점프, 코드를 데이터로 쓰는 방식 같은 변칙을 쓰지 않는다는 전제를 둠
  • 8080의 H와 L 레지스터는 8086의 BH와 BL 레지스터에 대응했고, 8080에서 계산된 주소 접근에 쓸 수 있던 레지스터가 HL뿐이었던 점이 8086에서 AX, BX, CX, DX 중 메모리 접근에 BX만 쓸 수 있었던 이유가 됨
  • MS-DOS는 CP/M 호환성 외에 환경 변수를 추가했지만, 기존 CP/M 프로그램은 환경 변수를 쓰지 않았기 때문에 초기 MS-DOS 프로그램도 환경 변수를 사용하지 않음
  • 사용자가 TEMP나 TMP를 설정할 수는 있었지만, 초기 프로그램들은 이를 신경 쓰지 않았음

시장에서 TEMP와 TMP가 경쟁함

  • 시간이 지나 MS-DOS를 주된 대상으로 삼는 프로그램이 작성되면서, 프로그램들이 환경 변수를 설정 데이터 저장 수단으로 활용하기 시작함
  • 임시 파일 위치를 지정하는 환경 변수로 TEMP와 TMP가 각각 쓰이기 시작했고, 둘이 주요 후보로 떠오름
  • 어느 변수를 먼저 확인할지는 프로그램 구현 선택에 따라 달라짐
  • 많은 프로그램은 양쪽을 모두 만족시키기 위해 TEMP와 TMP를 둘 다 확인했지만, 어느 쪽을 먼저 볼지는 구현마다 달랐음
  • 예전 DISKCOPY와 EDIT 프로그램은 TMP보다 TEMP를 먼저 찾았음

MS-DOS 2.0의 파이프와 TEMP

  • MS-DOS 2.0은 한 프로그램의 출력을 다른 프로그램의 입력으로 넘기는 파이프 기능을 도입함
  • MS-DOS는 단일 작업 운영체제였기 때문에, 파이프는 첫 번째 프로그램의 출력을 임시 파일로 리디렉션해 끝까지 실행한 뒤 두 번째 프로그램을 그 임시 파일에서 입력받도록 실행하는 방식으로 흉내 냄
  • 이 기능 때문에 MS-DOS 자체가 임시 파일을 만들 위치를 필요로 하게 됨
  • 그 임시 파일 위치를 제어하는 변수로 TEMP가 선택됨
  • COMMAND.COM이 TEMP를 선택했더라도 다른 프로그램들이 TEMP나 TMP 중 무엇을 쓸지는 여전히 각 프로그램의 선택으로 남음

Windows에서는 TMP가 우선되는 경로가 생김

  • Windows도 비슷한 과정을 거쳤지만, 초기 GetTempFileName 구현은 TEMP보다 TMP를 먼저 확인하도록 만들어짐
  • Windows 프로그램이 임시 파일을 만들 때 GetTempFileName을 사용하면 TMP를 더 선호하게 됨
  • 따라서 “어느 변수가 맞는가”에 대한 단일 답은 없고, 프로그램이 어떤 API나 자체 로직을 쓰는지에 따라 달라짐
  • 현재도 환경 변수 설정 대화상자에는 TMP와 TEMP가 둘 다 남아 있으며, 두 변수는 임시 파일 위치를 두고 계속 공존함

함께 보면 좋은 글 β

▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 흥미롭네. 내 시대 이전 일이라 CP/M 프로그램을 패치로 설정했다는 건 들어본 적이 없었음

    • 맞음, 실제로 그런 방식이 있었고 패치 코드는 Z80/8080 기계어여야 했음
      이 기능으로 내 WordStar에 더 빠른 키보드·화면 출력 루틴을 직접 작성했음
    • 맞음, 실제로 있었고, 원래 CP/M 프로그램이던 일부 프로그램은 DOS용 WordStar 7.0까지도 오래 이어졌음
      WordStar 7 문서에는 DOS의 debug.exe로 프로그램 동작을 바꾸는 데 쓸 패치 위치가 포함돼 있었던 것으로 기억함
    • 지금도 어느 정도는 남아 있음. suckless가 만드는 것들은 보통 config.h를 바꾸고 다시 컴파일해서 설정함
      https://suckless.org/
      덧붙이면, 이 페이지의 다른 하위 스레드에서 이미 언급된 걸 뒤늦게 봤음
    • 그 방식이 필요했던 건 RAM과 디스크 공간이 극도로 제한적이었고, 거의 모든 컴퓨터에 어셈블러가 딸려 있었기 때문임
      많은 CP/M 프로그램은 32K RAM과 느린 130K 플로피, 심하면 카세트테이프에서도 돌아가야 했음. 64K RAM과 360K 디스크가 있으면 꽤 특별한 축이었음
      당시에는 오늘날과 달리 프로그램을 시장 상단이 아니라 하단에 맞춰 최적화했음. 더 많은 시스템에서 돌아가야 더 많이 팔 수 있었고, 고객에게 하드웨어를 업그레이드하라고 떠넘기지 않았음
      외부 설정 파일이나 그 설정 파일을 만드는 프로그램을 둘 공간 자체가 없었고, 명령줄 인자 처리조차 귀한 바이트를 잡아먹었음
      요즘은 MacBook Neo의 RAM이 8,000,000,000바이트밖에 안 된다고 불평하지만, 1978년에는 2,048바이트짜리 기본 IDE도 만들 수 있었음

  • Raymond의 블로그는 좋아하지만, 1973년에 마이크로컴퓨터에서 CP/M이 흔했다는 건 이상함
    1973년의 마이크로컴퓨터는 Intel Intellec 같은 개발 시스템 수준의 시제품에 가까웠고, 운영체제도 없었음. Kildall이 CP/M 개발을 1973년에 시작한 건 맞지만, 그때는 PDP-10 메인프레임의 시뮬레이터에서만 돌아갔음
    1979년이면 몰라도 1973년은 너무 이름

    • Wikipedia에는 CP/M이 1974년에 만들어졌다고 되어 있으니, 여기의 시간표는 확실히 어긋나 있음
    • 1979년과 1973년의 차이가 지금의 2020년과 현재 사이 차이와 같다는 점이 재밌음
      그러고 보면 2020년에는 ChatGPT가 없었다고 생각하게 됨

  • 초기 개발자가 거의 고민하지 않고 내린 결정이 수십 년 동안 남는 좋은 예임

    • 잠깐 다뤘던 S&P500 제품의 핵심 테이블 하나는 앞으로도 영원히 attornies라는 이름일 것임. 초기에 아무도 오타를 잡지 못했기 때문임
    • TMPorary 결정만큼 영구적인 것도 없음

  • 프로그램들이 TMP를 고른 건 MS-DOS의 파일 확장자가 최대 3글자였고, 임시 파일 이름에 .TMP 확장자를 쓰던 관행 때문일 가능성이 큼

  • Unix 프로그램들이 http_proxy를 볼지 HTTP_PROXY를 볼지 일관되지 않았던 것과 비슷함
    요즘은 많은 프로그램이 둘 다 보지만, 확인 순서는 같지 않을 수 있음

  • CP/M 언급이 헷갈림. 글쓴이는 나중에 중요해질 거라고 해놓고, 결국 CP/M이나 8080 CPU와는 관련이 없었다고 설명하는 것처럼 보임

    • 동의함. 이 이야기는 CP/M도, 8080/8086으로 빠지는 곁가지도 별 관련이 없음
      핵심은 Microsoft가 직접 쓰면서도 표준화할 생각을 안 했다는 것뿐임
    • CP/M이 설정에 환경 변수를 썼다면, TMP와 TEMP 중 무엇을 쓸지 이미 표준이 생겼고 DOS가 그걸 따랐을 것임
      다만 진짜 걸림돌은 CP/M에는 디렉터리가 없었고, DOS 1.0에도 없었다는 점임
    • 어느 문장을 말하는 건지 인용해 줄 수 있음?

  • 1995년쯤 Telstra, 즉 Australia Telecom에서 조직 전체에 데스크톱이 약 5만 대 있었음
    어느 날 모두의 네트워크 홈 디렉터리에 null이라는 작은 파일이 생겼고, 아마도 Unix 사용자가 .bat 파일을 작성해 본 듯했음
    이미 존재하는 표준을 왜 따라야 하냐는 얘기임. “왜 표준화해야 하냐”고 묻고 싶었지만, 북미 사람들을 헷갈리게 할 수도 있겠다고 생각했음

    • 아마 처음에는 /dev/null을 시도했다가 실패해서 그냥 null로 바꾼 것 같음
      그렇지 않다면 Unix 프로그래머가 그랬다는 게 말이 안 됨. 오히려 DOS 프로그래머가 NUL을 null로 잘못 썼을 가능성이 큼
    • 버리려고 했던 텍스트가 뭐였는지 궁금함
    • 어떤 Logitech 드라이버 설치 프로그램도 비슷한 일을 했음
      하드디스크에서 NULL이라는 파일을 찾았고, 당연히 .BAT 파일 안에는 > NULL 같은 구문이 있었음

  • 솔직히 많은 프로그램에서 홈 디렉터리에 닷파일을 흩뿌리는 방식보다 CP/M식 패치 설정이 더 나았을 것 같음

    • 사람들이 XDG Base Directory Specification만 지키면 설정 파일 난립은 문제가 되지 않음
      Firefox 같은 버티던 프로젝트까지 포함해 점점 더 많은 프로젝트가 채택하고 있음
    • 약간 특이한 suckless 쪽 철학 중 하나가, 프로젝트를 대체로 소스 코드를 바꾸고 다시 컴파일해서 설정한다는 것임
      현대 오픈소스식으로 보면 비슷한 접근이라고 할 수 있음. 다만 전반적인 금욕주의 때문에 프로젝트들이 취향을 좀 탈 것 같음
    • 원래는 전부 .config 안에 있어야 함
      문제는 많은 앱 개발자들이 자기 앱만은 특별해서 별도 디렉터리를 가질 자격이 있다고 생각한다는 것임
    • 중앙의 바이너리 레지스트리 여기저기에 흩어진 설정보다는, grep하고 텍스트 편집기로 관리할 수 있는 닷파일이 낫다고 봄
      어쩌면 그냥 익숙해서 그럴 수도 있음
    • 이런 건 표준화됐으면 좋겠음. 어떻게든 .config 폴더를 강제할 수 있는 배포판이 있다면 나에게는 승자임
      다만 이미 타이밍을 놓친 것 같기도 함

  • 이렇게 혼란스러운 줄은 몰랐음
    교훈은 아마 항상 같은 경로를 가리키게 하라, 아니면 큰일 난다는 것임

  • Microsoft의 이런 짜증나는 것들을 수십 년 동안 짚어 왔음
    예전에는 거기서 모든 걸 안다는 듯한 “시니어 개발자”가 늘 답을 갖고 있었음. “temp는 temporary고 tmp는 troubleshoot my pc, 디버그 로그용이야. 그래서 내가 시니어고 넌 아니지” 같은 식이었음
    내가 더 시니어가 되고 보니 의문을 제기한 게 맞았고, 이제는 원래 Microsoft 개발자들과 이야기해 보면 실수였지만 하위 호환성 때문에 유지했다고 설명함
    그런데 그 변명이 왜 유효한지 묻게 됨. 하위 호환성을 이유로 삼으면서도 New Outlook처럼 핵심 호환성과 실제 업무 흐름을 자주 깨는 변경은 그대로 밀어붙이기 때문임. 그러면 “나는 나쁜 개발자가 아니니 새 사람들에게 물어보라”고 빠짐
    새 사람들에게는 물어볼 수도 없고, 그들은 LeetCode 선발 장벽 뒤에 숨어 있음. 그래서 이런 실제 문제가 고쳐지지 않고 New Outlook 같은 게 나오는 것도 이상하지 않음. 예전의 그 시니어 개발자가 이제 거기서 일하고 있고, 진짜 개발자들은 은퇴했음
    사용자 홈의 Documents 폴더를 임의 프로그램이 부적절하게 쓰거나 OneDrive가 실수로 강제로 지워 버리는 문제에 대해 Microsoft에서 그럴듯한 답을 받아도, 6개월 안에 Microsoft가 무작위 변경을 밀어 넣어 동작을 안 좋은 방향으로 바꾸면서 그 핵심 논리를 무너뜨림
    Notepad도 비슷함. 개발자 인터뷰에서는 위험이 0이어야 하므로 아주 단순한 프로그램이어야 한다고 말했는데, 나중에는 Microsoft 계정 로그인과 Copilot이 붙었음
    LeetCode식 개발자 태도와 Microsoft 문화가 업계 전체를 망친다고 봄. 차분한 토론이 안 되고, “넌 Microsoft에서 일하지 않으니 네 주장은 무효”로 흘러감
    Google Chrome이 관리자 권한을 우회하려고 AppData에 설치되던 일은 강하게 기억에 남음. 그 기능의 본래 의도가 제3자가 관리자 권한 없이 설치하려는 데 쓰라는 건 분명 아니었음
    하지만 당시 Chrome이 좋았고, 잠긴 기업 컴퓨터 수백만 대에 제3자 예외 프로그램을 배포하는 혼란을 처리해야 했으니, 개발자들은 이제 그걸 의도된 기능으로 다시 포장하고 있음

답변달기