成為 root：su -

su - 讓你從一般使用者切換成 root（系統管理員），整個 session 都以 root 身分操作。這個系列用到它，是因為在還沒有 sudo 的最小系統上，要裝 sudo、改系統設定，得先成為 root——而成為 root 的方式就是 su -，輸入 root 密碼後進入 root 的 shell。

那個 - 決定你載入哪一套環境。su - 啟動一個 login shell（模擬從頭登入、會跑完整的登入環境初始化），載入 root 自己的完整環境——把 PATH（shell 搜尋指令的目錄清單）換成 root 的（會包含 /usr/sbin 這類放管理工具的目錄）、工作目錄切到 root 的家。su（不加 -）則不啟動 login shell，環境多半沿用你呼叫時的、可能少掉那些管理工具目錄，於是有些管理指令會因為不在 PATH 裡而「找不到」，明明你已經是 root。所以要做系統管理，習慣用 su -。

su - 跟 sudo 解決的是不同情境。sudo 是「以 root 身分跑單一一條指令」，跑完就回到你自己；su - 是「整段都當 root」。這個系列先用 su - 是因為 sudo 還沒裝——一旦 sudo 裝好、wheel 群組（慣例上被授權可用 sudo 的群組）的授權設好，後面就改用 sudo <指令>，不再整段切 root。做完 root 的事，打 exit 回到原本的使用者。

用 nano 改設定檔

nano 是一個對照 vi 更直覺的文字編輯器，安裝過程改 locale.gen、hostname、sudoers 這些設定檔時會用到它。它的好處是所有快捷鍵都列在畫面最下面兩行，不必背。

那兩行裡的 ^ 符號代表 Ctrl 鍵。^O 就是 Ctrl+O、^X 就是 Ctrl+X。這個系列用到的幾個：

把這幾個串起來就是一次典型的設定檔編輯。以這個系列裡「解開 locale.gen 某一行的註解」為例：按 Ctrl+W 搜 en_US.UTF-8 UTF-8 跳到那行、用 Backspace 刪掉行首的 #、按 Ctrl+O 再 Enter 存檔、按 Ctrl+X 離開。改 hostname 則是 Ctrl+K 剪掉預設那行、打上新主機名、Ctrl+O、Ctrl+X。Ctrl+K 加 Ctrl+U 合起來就是「剪下再貼上」，是搬移整行的常見組合。

檔名與指令的大小寫

Linux 把大小寫當成不同的字元，這對檔名跟指令都成立。Setup 跟 setup 是兩個不同的東西、Documents 跟 documents 是兩個不同的資料夾、打 Sudo 不會執行到 sudo。這條規則貫穿整個系列：執行 archboot 的安裝程式是 setup（全小寫），啟動 Hyprland 桌面的指令是 Hyprland（首字母大寫），兩者差一個字母的大小寫就是不同的目標。

這對從 macOS 或 Windows 過來的人尤其常見，因為那兩個系統的預設檔案系統不分大小寫——在 Mac 上 File.txt 跟 file.txt 指向同一個檔，到了 Linux 就是兩個檔。同一個專案在 Mac 上跑得好好的，搬到 Linux 卻出現「檔案找不到」，常常就是某處大小寫對不上、而 Mac 的不分大小寫把問題藏了起來。

判讀方式很簡單：在 Linux 上，指令、檔名、路徑一律照原樣的大小寫打。錯誤訊息 command not found 或 No such file or directory 在你確定東西明明就在時，先懷疑大小寫。

shell 的幾個符號

這個系列的指令裡出現了幾個 shell 符號，它們是 shell 本身的語法、不是某個程式的參數，認得它們才讀得懂那些指令在做什麼。

> 跟 >> 是重導向，把本來會印到畫面的輸出改寫進檔案。> 覆蓋、>> 追加。系列裡 echo '%wheel ALL=(ALL:ALL) ALL' > /etc/sudoers.d/10-wheel 就是把那行文字寫進一個新檔，而設 authorized_keys 時用 >> 是為了追加、不洗掉既有的 key。

|（管線）把左邊指令的輸出，直接餵給右邊指令當輸入。傳 dotfile 進 VM 的 tar czf - . | ssh host 'tar xzf -' 就是把 tar 打包的資料流，不落地直接透過 ssh 送到對面解開。

&& 串接兩條指令，而且只有左邊成功才跑右邊。cd ~/dotfiles && ./scripts/install.sh 的意思是「先切到目錄，切成功了才跑腳本」——如果目錄不存在、cd 失敗，後面的腳本就不會在錯的目錄下執行。

$(...) 是命令替換，把括號裡指令的輸出，當成值填進當下這條指令。chsh -s "$(command -v zsh)" 會先跑 command -v zsh 得到 /usr/bin/zsh，再把這個路徑填給 chsh。理解這個語法，也才看得懂 工具驗證篇 講的 which 地雷：當 which 不存在、$(which zsh) 算出空字串，整條指令就拿到一個空值。

跟重導向相關的還有一個經典陷阱：sudo echo '內容' > /etc/某個-root-檔 會失敗。原因是重導向 > 由你的 shell 以你的身分執行，不是被 sudo 提權的那條指令——被提權的只有 echo，真正寫檔的還是你，而你沒權限寫那個 root 檔。解法是 echo '內容' | sudo tee /etc/某個-root-檔：tee 把流進它的 stdin 寫進檔案，而 tee 才是被 sudo 提權的那支，所以寫得進去。這個系列補 sudoers 檔時用的就是這個寫法。

權限對某些檔是硬要求，所以系列裡出現了 chmod。chmod 改檔案權限，那串數字是八進位的權限碼，三位分別代表擁有者/群組/其他人；每一位是讀（4）+ 寫（2）+ 執行（1）的和，所以 7 是全權、6 是可讀寫、4 是只讀、0 是無權。系列裡的 chmod 440（擁有者與群組可讀、其他人無權，給 sudoers 檔）、chmod 600（只有擁有者可讀寫，給私鑰）、chmod 700（只有擁有者全權，給 .ssh 目錄）就是這樣算出來的。這些檔對權限有要求——sudoers 必須是 440、私鑰必須只有自己讀得到，否則對應的工具會拒絕使用它們，所以那幾個 chmod 不是裝飾、是讓 sudo 跟 ssh 願意接受那些檔的條件。

下一步

認得這些基礎操作之後，就可以從 安裝選項判讀 開始走完整的安裝流程，過程中再遇到這幾個操作就不會卡。

Zsh vs Bash 的配置檔載入順序

理解配置檔的載入順序是結構化拆分的前提。不知道哪個檔案在什麼時機被讀取，就無法判斷設定該放在哪。

Bash 的載入順序

Bash 區分 login shell 和 non-login shell，兩者讀取的檔案不同：

• Login shell（SSH 進來、bash --login）：讀 ~/.bash_profile（如果不存在，依序嘗試 ~/.bash_login → ~/.profile）
• Non-login interactive shell（開一個新終端機視窗）：讀 ~/.bashrc
• 常見做法：在 ~/.bash_profile 裡 source ~/.bashrc，確保設定不管怎麼進來都一致

Zsh 的載入順序

Zsh 的載入鏈比 Bash 更細緻：

1. ~/.zshenv — 每次都讀（login、non-login、script 都會），放環境變數
2. ~/.zprofile — 只有 login shell 讀，對應 Bash 的 ~/.bash_profile
3. ~/.zshrc — interactive shell 讀，放 alias、function、prompt、plugin
4. ~/.zlogin — login shell 在 .zshrc 之後讀（少用）
5. ~/.zlogout — logout 時讀（少用）

實務上 90% 的設定都進 .zshrc，環境變數（PATH、EDITOR）放 .zshenv。

結構化拆分：從單一巨檔到模組化

一個典型的失控 .zshrc 長這樣：PATH 設定、alias、function、plugin 載入、prompt 配置、各種工具的 eval/source 全混在一起，改一個東西要在五百行裡找位置。

模組化的目標是依職責拆檔，.zshrc 本身只負責 source 這些模組：

 1# ~/.zshrc — 只做 source，不放具體設定
 2
 3# 環境變數（PATH 在 .zshenv，這裡放其他 interactive 專用的）
 4source "$HOME/.config/zsh/env.zsh"
 5
 6# Alias
 7source "$HOME/.config/zsh/aliases.zsh"
 8
 9# Function
10source "$HOME/.config/zsh/functions.zsh"
11
12# Plugin manager
13source "$HOME/.config/zsh/plugins.zsh"
14
15# Prompt / theme
16source "$HOME/.config/zsh/prompt.zsh"
17
18# 工具整合（fzf, nvm, pyenv, etc.）
19source "$HOME/.config/zsh/tools.zsh"
20
21# 機器專屬設定（不進 Git）
22[[ -f "$HOME/.config/zsh/local.zsh" ]] && source "$HOME/.config/zsh/local.zsh"

各模組的職責

aliases.zsh — 短指令對映

 1# 檔案操作
 2alias ll='ls -alF'
 3alias la='ls -A'
 4
 5# Git 常用
 6alias gs='git status'
 7alias gd='git diff'
 8alias gco='git checkout'
 9alias gp='git push'
10
11# 導航
12alias ..='cd ..'
13alias ...='cd ../..'

判讀準則：alias 適合「不帶參數的簡單替換」。如果需要參數處理或條件判斷，改用 function。

functions.zsh — 帶邏輯的常用操作

1# 建目錄並進入
2mkcd() {
3    mkdir -p "$1" && cd "$1"
4}
5
6# 在 Git repo 根目錄搜尋
7ggrep() {
8    git grep "$@" "$(git rev-parse --show-toplevel)"
9}

tools.zsh — 第三方工具的初始化

1# fzf
2[[ -f ~/.fzf.zsh ]] && source ~/.fzf.zsh
3
4# nvm
5export NVM_DIR="$HOME/.nvm"
6[[ -s "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh"
7
8# pyenv
9command -v pyenv >/dev/null && eval "$(pyenv init -)"

每個工具的 init 前面加存在性檢查（command -v 或 [[ -f ]]），避免在沒裝該工具的機器上報錯。

local.zsh — 機器專屬、不進 Git

1# 公司 VPN 設定
2export CORP_PROXY="http://proxy.corp:8080"
3
4# 只有這台機器需要的 PATH
5export PATH="$HOME/corp-tools/bin:$PATH"

在 dotfile repo 的 .gitignore 裡排除這個檔案。.zshrc 裡用 [[ -f ... ]] && source 確保不存在也不報錯。

概念位置

Shell（zsh / bash）執行一個程式時、預設讓程式佔住 terminal、stdin / stdout / stderr 直接連到使用者眼前的視窗、稱為前景 process。指令尾巴加 & 改成背景 process、shell 立刻拿回 prompt 控制權、程式繼續跑但不佔住 terminal。背景 process 仍綁在當前 shell session、關掉 terminal 視窗時通常會被 SIGHUP 終止；要完全脫離 shell 生命週期、得改用 launchd service 或 nohup / disown 等機制。

可觀察訊號與例子

shell 控制 process 的關鍵操作：

排錯常用的兩個工具（兩者跟 shell job 不直接相關、是 macOS 系統工具）：

對 macOS 新手最常遇到的兩個事故：一個是「前景跑 server 後不知道怎麼脫身」、解法是 Ctrl+Z 暫停 + bg 改背景、或下次改用 & 啟動；另一個是「pkill 沒指定夠精確的 pattern、誤殺其他 process」、解法是先用 ps aux 加 grep 確認 PID 再 kill。

設計責任

選前景 vs 背景的判讀：debug 場景前景跑、能直接看到 log；日常使用改 launchd service 跑、跟 shell session 完全脫鉤。& 適合「terminal 開著就讓它跑、關掉也沒關係」的臨時場景、不適合需要長期穩定的服務。排錯時養成「先 lsof 找誰佔資源、再 ps 確認身分、最後才 kill」的順序、避免誤殺。

PATH 管理

PATH 是最容易腐化的環境變數——每裝一個工具就加一條，最後 PATH 變成一長串看不懂的路徑，順序還會互相影響。

管理原則：

• PATH 設定集中在一個地方（.zshenv 或 env.zsh），不散落在多個檔案
• 新增前先想：這個路徑是所有機器都需要、還是特定機器才需要？共用的進 env.zsh，特定的進 local.zsh
• 用 typeset -U PATH (Zsh) 自動去除重複項目，避免多次 source 導致 PATH 不斷加長

1# ~/.config/zsh/env.zsh
2typeset -U PATH  # 去重
3
4# 自己的 script
5export PATH="$HOME/.local/bin:$PATH"
6export PATH="$HOME/bin:$PATH"

Plugin Manager 選型

Zsh plugin manager 的選擇很多，差異主要在載入速度和功能豐富度：

• 無 plugin manager：直接 git clone plugin 到某個目錄，手動 source。最簡單、最透明、但更新要自己管
• zinit（原 zplugin）：載入速度最快（turbo mode 延遲載入）、功能最多、但配置語法學習曲線高
• antidote：宣告式（一個 .zsh_plugins.txt 列出所有 plugin），概念簡單
• sheldon：Rust 寫的、速度快、設定用 TOML

常用 plugin：

• zsh-autosuggestions：根據歷史指令自動補全建議（灰色字，按右箭頭接受）
• zsh-syntax-highlighting：指令行即時語法高亮
• zsh-completions：額外的 tab 補全定義

Prompt 設計

Prompt 是每次按 Enter 都會看到的東西，值得花時間設計但不需要複雜。

基本款（不用框架）：

1# 顯示目錄 + git branch
2autoload -Uz vcs_info
3precmd() { vcs_info }
4zstyle ':vcs_info:git:*' formats ' (%b)'
5PROMPT='%F{blue}%~%f%F{green}${vcs_info_msg_0_}%f %# '

框架款：Starship（跨 shell、用 TOML 設定、Rust 寫的速度快）是目前最常被推薦的 prompt 工具。它的配置進 ~/.config/starship.toml，也是 dotfile 的一部分。

Dotfile 結構對應

管理工具與目錄結構裡的 stow 目錄結構，shell 配置的對應：

 1~/dotfiles/
 2└── zsh/
 3    ├── .zshenv
 4    ├── .zshrc
 5    └── .config/
 6        └── zsh/
 7            ├── aliases.zsh
 8            ├── functions.zsh
 9            ├── plugins.zsh
10            ├── prompt.zsh
11            ├── tools.zsh
12            └── env.zsh

stow zsh 會在家目錄建立 .zshenv 和 .zshrc 的 symlink，在 .config/zsh/ 下建立各模組檔案的 symlink。local.zsh 不在 repo 裡，各機器自己建。

章節文章

跨分類引用

• → 模組一：管理策略：stow 的 package 概念怎麼對應 shell 配置的目錄結構
• → 模組一：跨平台共用一個 Repo：path.zsh 和 tools.zsh 裡的 OS 分流做法
• → 模組三：終端機與編輯器：terminal emulator 的配色跟 shell prompt 的配色協調