最近釋出的 Bash INI 解析器庫引發了開發者之間的激烈討論，探討何時應該放棄 shell 指令碼而轉向更強大的程式語言。這個提供直接在 Bash 中解析和操作 INI 配置檔案功能的庫，已成為指令碼和自動化最佳實踐討論的焦點。
Shell 指令碼的複雜度閾值
社群討論揭示了開發者中的一個共識：shell 指令碼有一個自然的複雜度閾值，超過這個閾值就會變得難以管理和維護。許多開發者都建立了個人規則來確定何時從 Bash 遷移到更結構化的語言。
「我一直遵循的規則是，一旦 shell 指令碼變得過於複雜，就該用真正的程式語言重寫它。這個庫已經遠遠超過了那個閾值。」
這些閾值在開發者之間各不相同，有些人提出具體的指標，如超過一個迴圈、超過一個 if 語句、超過 100 行程式碼或定義超過三個函式，都是該轉換語言的訊號。其他人則指出需要引數解析或複雜資料結構作為關鍵指標。共識似乎是 shell 指令碼應該保持相對簡單的膠水程式碼角色，而將更復雜的功能交給其他語言處理。
開發者放棄 Shell 指令碼的閾值
- 程式碼行數：超過 100 行
- 函式數量：超過三個函式
- 控制結構：超過一個迴圈、巢狀迴圈或 if 語句
- 複雜度指標：
- 需要引數解析
- 檔案格式解析
- 管道超過 80 個字元
- 複雜資料結構
Bash INI 解析器的替代方案
- 使用標準庫 INI 解析器的 Python
- crudini 工具 (https://github.com/pixelb/crudini)
- 在 CI/CD 環境中使用 Git 解析 INI 檔案
- INI 轉 JSON 轉換器與 jq 配合使用（但會丟失註釋）
- 使用 IPC::Run 和 Getopt::Declare 等模組的 Perl
- 帶有 shell API 的 Bun.js
Python 作為首選替代方案
Python 成為最常被推薦用來替代複雜 shell 指令碼的語言。開發者強調其標準庫的電池包含方法，特別指出 Python 內建的 INI 檔案解析器消除了對複雜 Bash 實現的需求。選擇 Python 的理由主要集中在與複雜 Bash 指令碼相比，它提供了更好的可靠性、可除錯性和可讀性。
然而，Python 推薦也有一些注意事項。一些開發者指出 Python 歷史上的版本相容性問題，系統可能透過不同命令訪問不同版本。其他人提到包管理挑戰，不過像 uv 和 PEP 723 內聯指令碼元資料等新工具被認為是解決這些問題的方案。
堅持使用 Shell 指令碼的理由
儘管有向更結構化語言轉變的趨勢，一些開發者仍然為在特定場景下堅持使用 shell 指令碼提出了有力的論據。一位開發者熱情地為 shell 指令碼辯護，認為批評往往源於程式設計正規化與語言之間的不匹配。他們建議 shell 指令碼在執行線性步驟集合方面表現出色，並且當以資料優先設計進行適當組織時，可以保持可維護性。
另一個被提到的重要優勢是壽命和相容性。幾十年前編寫的 shell 指令碼通常可以在現代系統上執行，幾乎不需要修改，與可能面臨破壞性變更或依賴性問題的其他語言相比，提供了卓越的永續性。
現實世界的約束
討論也承認有時需要像 Bash INI 解析器這樣的解決方案的實際現實。一位貢獻者提到繼承了一個擁有超過 50,000 行 shell 指令碼的遺留專案，突然需要解析 INI 檔案並將值載入到環境變數中——這正是該庫解決的用例。
幾種替代方法被提出，包括使用現有工具如 crudini，利用通常存在於 CI/CD 環境中的 Git 解析 INI 檔案，或建立 INI 到 JSON 的轉換器並使用 jq 進行操作——儘管後一種方法會丟失 INI 檔案中的註釋。
這場辯論最終凸顯了軟體開發中理論最佳實踐與實際約束之間的張力。雖然大多數開發者同意在 Bash 中進行復雜配置解析超過了理想的複雜度閾值，但他們也認識到現實世界的專案有時需要務實的妥協。
對於那些必須在 shell 指令碼中處理 INI 檔案的人來說，Bash INI 解析器提供了一個全面的解決方案——但它的存在本身就提醒人們關於何時轉向更強大的程式設計工具的持續討論。