$4 blog: 2026

2026年1月6日星期二

深入解析 grep 的「Broken pipe」錯誤：隨機出現的原因與優雅解法

最近我在 [ChromeOS Flex](https://chromeos.google/products/chromeos-flex/) 的 Linux 環境中使用 [Homebrew](https://brew.sh/) 時，總是會隨機看到 `grep: write error: Broken pipe`。後來去檢查相關程式碼，發現是這行 `grep -E "^(flags|Features)" /proc/cpuinfo | grep -q "ssse3"` 指令造成的。這個錯誤雖然不一定影響最終結果，但在特定環境下出現總是讓人感到困惑。為什麼這行看似普通的管線指令會隨機報錯？今天就來深入探討其成因，並提供修正方案。 ## 「破裂的管線」錯誤成因這個錯誤的核心，在於 Linux 作業系統處理**行程（Process）**與**管線（Pipe）**的機制。當我們執行上述指令時，發生了以下連鎖反應： 1. **前端寫入（Producer）**：第一個指令 `grep -E ...` 負責讀取 CPU 資訊，並持續將符合條件的資料寫入管線。 2. **後端讀取與提早退出（Consumer）**：管線另一端的 `grep -q "ssse3"` 負責接收資料。關鍵在於 `-q` (quiet) 參數，它告訴 `grep` 一旦找到 "ssse3"，就**立即停止讀取並退出程式**。 3. **管線斷裂（Broken Pipe）**：當後端 `grep` 退出後，管線的讀取端隨之關閉。然而，前端的 `grep` 此時可能還在嘗試寫入剩餘的資料。當它試圖寫入這條「已關閉」的管線時，系統便會發送 **SIGPIPE** 訊號，導致行程終止並印出 `write error: Broken pipe`。 ## 為何錯誤是隨機出現的？既然機制如此，為何不是「每次」都報錯？這歸因於**競爭條件（Race Condition）**。電腦的排程器決定了兩個程式執行的快慢： * **沒事發生的情況**：前端 `grep` 產出資料的速度夠快，或者資料量剛好夠小，在後端退出前就已經寫完並結束了。 * **報錯的情況**：後端 `grep -q` 很快就找到了 "ssse3" 並關閉管線，而前端還來不及寫完剩下的資料，導致寫入失敗。這種執行時間上的微小差異，決定了你是否會看到這行錯誤訊息。 ## 更優雅的解決方案既然問題出在「多個指令透過管線傳輸」的時間差，最穩健的解法就是**避免使用管線**，將邏輯整合到單一 `grep` 指令中。我們可以將原本的指令： ```bash grep -E "^(flags|Features)" /proc/cpuinfo | grep -q "ssse3" ``` 改寫為： ```bash grep -qE '^(flags|Features).*\bssse3\b' /proc/cpuinfo ``` ### 改寫後的優點： * **消除競爭條件**：單一行程運作，完全根除「管線破裂」的可能性。 * **效能提升**：省去了啟動兩個行程與建立管線的開銷。 * **精準度提高**： * `^(flags|Features)`：鎖定行首。 * `.*\bssse3\b`：利用 `\b`（單詞邊界）精確匹配 "ssse3"，避免誤判類似字串。下次若在 Script 中發現類似的隨機管線錯誤，不妨檢查是否使用了會提早退出的指令（如 `grep -q`、`head` 等），並嘗試將其整合以提升穩定性！順便生了一個 [pull request](https://github.com/Homebrew/brew/pull/21366) 給 Homebrew