在命令列介面的世界中，一致性和可預測性至關重要。最近出現了一個名為 argp 的 Go 語言包，承諾提供符合 GNU 標準的命令列引數解析器。然而，它的釋出在開發者中引發了關於 CLI 標準、相容性問題以及遵循既定慣例與引入新方法之間持續緊張關係的重大討論。
CLI 標準之爭
這個新解析器的引入重新點燃了一場關於開發者應該遵循哪種命令列介面標準的長期爭論。雖然該軟體包聲稱實現了 GNU 風格的引數解析，但一些評論者指出它與實際的 GNU 標準存在不一致之處。一個明顯的偏差是對選項多值的處理方式。軟體包文件表明 -a 1 2 3 會將所有三個值分配給選項 a，而傳統的 GNU 風格會將其解釋為帶有值 1 的選項 a，後跟兩個位置引數。
「總的來說，命令列引數解析器應該只遵循 GNU 風格。不多也不少。偏離標準會讓使用者感到困惑，因為他們無法立即明白解析器施加的規則。」
這種觀點反映了開發者的普遍挫折感，他們必須在不同工具間應對不一致的 CLI 行為。POSIX 標準早於 GNU 慣例，甚至更加嚴格，根本沒有定義長選項。這導致了一個分散的格局，不同社群（Go、Python、Java）開發了自己的 CLI 慣例，這常常讓期望一致行為的使用者感到失望。
Go 語言中流行的命令列解析器
- 標準庫 flag：簡單的 Go 風格標誌（
-flag=value） - Cobra/pflag：帶有自動完成支援的 GNU 風格標誌
- Kong：高階功能，如標誌分組和環境變數關聯
- urfave/cli：流行的替代方案，具有良好的開發者體驗
- go-flags：基於結構體的方法，使用標籤
- argp：新的 GNU 風格解析器，支援結構體標籤
GNU 命令列規則
- 當引數以連字元
-開頭時，它們被視為選項 - 多個短選項可以組合：
-abc等同於-a -b -c - 長選項以兩個連字元開頭：
--verbose - 選項值可以用空格、等號或無分隔符分隔
- 選項和非選項可以交錯使用
--終止所有選項- 單個
-被視為非選項
相容性問題和邊緣情況
討論中提出的一個特別有爭議的問題涉及短選項中等號的處理。軟體包文件宣告 -a=1 等同於 -a 1，但這可能會在像 cut 這樣的工具中造成問題，其中 -d= 是常見的使用模式。如果等號被解析器吞掉，它會以潛在破壞性的方式改變行為。
這凸顯了一個更廣泛的挑戰：向後相容性。依賴特定 CLI 行為數十年的 Shell 指令碼和使用者工作流可能會在新工具實現不同的解析規則時崩潰。一些評論者分享了這些不一致造成問題的真實案例，例如在 Gentoo 包管理中，精確的包名必須以等號開頭。
命令列解析器生態系統
討論揭示了 Go 社群已經有幾個成熟的命令列解析器，具有不同的方法和功能集。Cobra（與 pflag 一起）、Kong 和 urfave/cli 被頻繁提及為成熟的替代方案。每一個都有其優勢 - Cobra 提供自動 shell 補全，Kong 能很好地處理複雜的 CLI 介面，而 go-flags 提供了類似於新包的基於結構體的方法。
這種碎片化引發了是否需要另一個解析器的疑問，特別是一個引入自己對 GNU 標準解釋的解析器。一些開發者表達了對 Go 標準庫 flag 包不遵循 GNU 慣例的失望，而其他人則為 Go 更簡單的方法辯護，認為它在自己的生態系統中更加一致。
反射和效能考慮
一些開發者提出的技術問題是新解析器中結構體標籤和反射的使用。雖然這種方法實現了一種乾淨、宣告式的定義命令列選項的風格，但它也帶來了潛在的缺點。反射可能影響效能並在編譯期間停用死程式碼消除，可能導致更大的二進位制檔案大小。它還將驗證從編譯時移到執行時，一些開發者認為這是有問題的。
圍繞結構體標籤的爭論突顯了 Go 開發中更廣泛的緊張關係，即遵循慣用模式與最佳化效能和安全性之間的平衡。雖然許多流行的 Go 包使用反射和結構體標籤（如 encoding/json），但一些開發者更喜歡顯式程式碼而非神奇的執行時行為。
最終，圍繞這個新命令列解析器的討論反映了平衡標準合規性、使用者期望和語言習慣的持續挑戰。雖然有選擇是有價值的，但 CLI 解析略有不同的方法的擴散繼續為開發者和使用者創造摩擦。正如一位評論者所指出的，也許最重要的不是哪個標準最好，而是工具一致地遵循使用者可以依賴的某種標準。