Linux /usr 目錄不是 User 的縮寫嗎？
50年前的「硬體事故」帶來的蝴蝶效應
使用 Linux 或 Unix 系統時，你可能也會想過這個問題。
"到底
/usr是什麼的縮寫？"
乍一看好像是把 User 的 e 去掉了。
如果是這樣，為什麼不直接寫 /user 呢？
- 是因為打字麻煩？
- 有字數限制嗎？
- 但像
/boot、/home、/proc這樣四個字的目錄還是存在。
如果真的代表「使用者（user）」，那就應該寫 /user。
為什麼還要用模糊的 /usr 呢？其實背後隱藏著一段我們不知的歷史。
今天，我們將揭開這個 /usr 目錄背後的故事，帶你走進一段 50 年前的「可笑」硬體歷史，讓開發者在閱讀時不禁會心一笑。
1. 結論先說：現在的 /usr 不是「User」
在目前的 Linux 文件系統標準（FHS，Filesystem Hierarchy Standard）中，/usr 被定義為：
系統全域使用、（大多）只讀的程式、函式庫、共享資料所在區域
因此，我們常見的結構就是：
/usr/bin– 大部分使用者執行檔/usr/sbin– 系統管理執行檔/usr/lib*– 這些執行檔使用的函式庫/usr/share– 手冊、圖示、語言資料等架構獨立資料
無論從哪裡看，這都與「使用者個人檔案」相距甚遠。
家目錄（~/...）或文件、照片等都在 /home 之下。
從今天的觀點來說，簡單定義 /usr 為：
/usr= 「不是 User，而是 OS 與應用程式的『共用系統資源倉庫』」
那麼，還剩下一個問題：
「那麼
usr不是 User 的縮寫嗎？」
這裡就出現了趣味的轉折。 最初的確是「User」的縮寫，但之後 50 年的使用方式完全被顛倒。
2. 初期 Unix：/usr/帳號名 是家目錄
回到 1970 年代初期的 Unix 時代。
當時 Unix 系統的家目錄不是像現在的 /home/alice，而是
/usr/alice這樣直接放在/usr之下。
也就是說，當時的 /usr 真正是：
「用戶相關的東西放進去的目錄」
那時的電腦是 PDP‑11 等設備，磁碟容量比今天小得多。
- 根磁碟（
/） – 只放 OS 核心檔案的狹窄空間 - 第二磁碟（
/usr） – 相對寬裕的空間，放置使用者家目錄
這樣的結構在當時是合理的。
3. 「磁碟滿了」 → 把系統檔案搬到 /usr
Unix 持續成長，新的指令與功能不斷加入。
問題是 根磁碟（/）的容量保持不變。
最終有一天，情況變成：
「已經沒有空間放程式到
/了…」
開發者做出了實際的選擇：
「既然第二磁碟（
/usr）空間充足， 把不必在啟動時立即使用的程式搬到那裡。」
於是，最初是「用戶家目錄」的 /usr，開始慢慢被
程式、函式庫、資料 逐漸塞滿。
結果就是我們現在熟悉的結構：
/bin– 必須在啟動時使用的「最小」指令（原本在根磁碟）/usr/bin– 其餘一般指令（搬到第二磁碟）/libvs/usr/lib也類似
簡而言之：
原本是「用戶家」的
/usr，因為「空間多」而被系統檔案「搬進」來。
這就是「硬碟容量不足所帶來的權宜之計」。
隨後 Unix 繼續發展：
- 用戶家目錄搬到
/home等更直觀的目錄 /usr完全成為「共用程式/函式庫區」
這時的情況已經相當滑稽：
- 名稱：
usr（user） - 實際內容：系統與應用程式專用檔案
房主搬走，房子卻被系統檔案佔滿。
4. 「Unix System Resources」？那是後來才起的說法
這種矛盾的情況持續了很久，後來有人開始說：
「現在
/usr可以說是 Unix System Resources 的縮寫。」
你可能在某些文件中見過「/usr = Unix System Resources」的說法。 但關鍵是：
這是 後來插入的 backronym，並非最初設計時的正式意義。
早期 Unix 文檔與證言顯示：
/usr原本是 user 的縮寫/usr/帳號名用來放家目錄- 之後因磁碟容量問題，意義逐漸擴張到「用戶使用的程式」→「程式與函式庫」
隨著時間推移，人們把現實簡化為：
「現在
/usr是放系統資源的地方，叫做 Unix System Resources。」
這種做法稱為 backronym：先有縮寫，再後面賦予意義。
在開發者圈子裡，這種現象相當常見：
- 暫時的名稱/結構
- 進入文件
- 成為標準
- 最後被解釋為「本來就這樣」
5. 50 年前的結構至今：Usr Merge
聽完這些，你可能會想：
「如果磁碟空間足夠，為什麼還要把
/bin、/usr/bin分開？」
實際上，現代 Linux 發行版（Ubuntu、Fedora、Debian 等）正試圖整理這段歷史，這就是 /usr merge（UsrMerge）。
在最近的發行版中，試試以下指令：
$ ls -l /
lrwxrwxrwx 1 root root 7 ... bin -> usr/bin
lrwxrwxrwx 1 root root 7 ... sbin -> usr/sbin
lrwxrwxrwx 1 root root 7 ... lib -> usr/lib
大多數情況下會看到這樣的結構。
/bin其實不是實際目錄，而是 指向/usr/bin的符號連結/sbin、/lib亦同
也就是說，今天的實際結構是：
「大部分程式與函式庫都在
/usr之下」
為什麼要合併？原因多樣，但主要包括：
- 套件管理/移植更簡單
- 容器/映像部署時，將
/usr視為「整個系統映像」更方便 - 舊硬體限制已不再需要維持分離結構
有趣的是，所有這一切的起點都是：
「1970 年代磁碟太小，程式被塞進
/usr」
這正是「臨時解決方案永遠不會真正永久」的典型例子。
6. 那麼今天我們該如何理解 /usr？
在實際操作 Linux 系統時，對 /usr 的理解可以這樣：
「這個系統共用的程式、函式庫、共享資料所在區」
相對地：
- 個人檔案 / 設定 →
/home/你的帳號 - 經常變動的資料（日誌、快取、資料庫等） →
/var - 非發行版套件、手動安裝的應用程式 → 通常在
/opt或/usr/local下
簡而言之：
/usr是 OS 與應用程式的世界/home是 使用者個人的世界
這樣區分後，混淆就會大幅減少。
7. 總結：一個目錄名稱背後的開發者妥協
/usr 這個目錄包含：
- 「磁碟容量不足的早期 Unix 開發者」的實際考量
- 「先這樣做，之後再整理」的常見妥協
- 之後數十年來的標準化與整理工作（UsrMerge）
比起單純記住：
- 「
/usr= Unix System Resources」 - 「
/usr不是使用者目錄」
了解這段背景後，當你在終端看到 /usr/bin、/usr/lib 時，會有更深的感觸：
「這是 50 年前硬碟空間不足所留下的遺產。」
在黑色螢幕中的一個目錄，竟然蘊藏著那段硬體限制與開發者妥協的歷史，這不正是開發者最喜歡的趣事嗎？
目前沒有評論。