
為什麼同時存在 TMP 與 TEMP 環境變數?
這篇文章探討了 TMP 與 TEMP 環境變數的歷史演變,追溯其起源從 CP/M 缺乏此類變數開始,到 MS-DOS 與 Windows 採用了相互衝突的標準。
背景
這篇文章探討了 Windows 系統中同時存在 TMP 與 TEMP 兩個環境變數的歷史淵源。作者 Raymond Chen 指出,這兩個變數的並存源於早期 MS-DOS 時代缺乏統一標準,導致不同開發者各行其道,甚至連微軟內部的不同工具對這兩個變數的讀取優先順序也完全相反。
社群觀點
在 Hacker News 的討論中,社群成員對這段歷史展現了濃厚的興趣,特別是針對早期軟體開發的「手動時代」進行了深入討論。原文提到的 CP/M 時代透過「補丁」(patching)二進位檔來進行配置的作法,引發了許多資深開發者的共鳴。有留言者回憶起當年 WordStar 等軟體甚至會提供手冊,指導使用者如何修改特定位元的機器碼來支援自定義印表機或優化效能。這種直接修改執行檔的作法在現代看來雖然原始,但卻被部分開發者認為比現在散落在使用者目錄下各處的隱藏設定檔(dotfiles)更為乾淨。
關於環境變數與路徑標準化的爭議,社群中出現了對現代標準執行不力的感嘆。雖然 Linux 領域有 XDG 基本目錄規範,Windows 也有對應的應用程式資料夾路徑,但許多開發者仍傾向於在主目錄下建立專屬資料夾,這種「自認特殊」的開發習慣導致了系統環境的混亂。討論中也提到,這種混亂不僅限於變數名稱,甚至延伸到虛擬設備的命名。例如有網友分享在自動化腳本中誤將 NUL 寫成 null,導致系統產生了一個名為 null 的實體檔案而非丟棄輸出,這反映出開發者在跨平台遷移時,常因對不同系統底層慣例的混淆而產生錯誤。
此外,針對「透過修改原始碼並重新編譯來配置軟體」的哲學,社群也展開了辯論。部分開發者推崇如 suckless 系列軟體的極簡主義,認為這能確保軟體輕量且無多餘依賴;但另一派觀點則認為,隨著生活與工作節奏加快,手動解決合併衝突或編譯問題已不再具備效率。最終,社群達成了一種務實的共識:在環境變數混亂的現狀下,最保險的做法是確保 TMP 與 TEMP 始終指向同一個路徑,以避免不同程式因讀取偏好不同而將暫存檔散落在各處。
延伸閱讀
- XDG Base Directory Specification:Linux 系統中嘗試標準化設定檔、資料與快取路徑的規範。
- st-flexipatch:一個針對 suckless terminal (st) 的專案,旨在簡化手動修補原始碼的繁瑣過程。
- Windows 已知資料夾路徑:建議開發者使用
SHGetKnownFolderPath搭配FOLDERID_LocalAppData來定位暫存與應用程式資料,而非硬編碼路徑。
相關文章