getopt_long VS getopt_long_only

Question

做一個適當的Linux/UNIX風格的應用程序，什麼是最好的選擇（例如，據我所知LS使用getopt_long但例如的ffmpeg getopt_long_only）。你推薦 哪一個？

乾杯，

Answer 1

都沒有。用戶argp_parse或libpopt。

Answer 2

我從來沒有getopt_long_only使用，但它似乎將不得不做更多的查找，因爲它必須看長期和短期兩個選項，如果一個未知的標誌和一個-開始：

如果開頭的選項「 - 」（不 「 - 」）不匹配的長選項，但 不匹配短選項，它是 解析爲，而不是一個短期的選擇。

- man getopt_long_only

Answer 3

我說的「正確的GNU/Linux的風格」，你應該使用getopt_long（）和大多數選項（有時是長選項）提供長期的選項。大多數命令行界面都遵循這個。

Answer 4

在我看來，下面的東西通常是正確的：

• 用戶喜歡長髮，自然語言的選擇，因爲它們很容易記住。
• 誰編寫腳本的用戶來包裝有數百個選項愛短選項程序。

如果一個程序變得足夠大，它將最終用完短期選項組合，與規範選項相比，它們會有任何意義。例如，-Z可能是相同於一個完全不同的字母開頭的長選項。在這一點上，尤其是對於一個維護者，解析代碼的選項成爲一件令人頭疼的維護。

您有幾種選擇，當出現這種情況：

• 使用類似gengetopt編寫代碼，您從模板
• 僅使用長選項（通常是一個壞主意）
• 嘗試和保持你的程序下降到52個選項（AZ AZ）（通常是一個糟糕的主意）
• 實現短選項變成不帶參數的開關的選項，對那些選項使用長選項
• 其他方法對你很有意義，對用戶的意義不大

混合在不同的語言環境中，你真的開始抓住痛苦。

當我坐下來寫一個工具，需要很多的選擇，我通常做的第一件事就是寫代碼來解析參數，這有助於規劃程序的流程，成爲一個大綱。在此之後，您只需讓每個選項都有效。換句話說，如果你的選擇成爲這樣的慢性疼痛，它通常表示一個程序，它很快就會超出其規劃。無論如何，爲了讓我的漫長回答結束，通常儘可能保持compat getopt（）行爲。從用戶那裏獲取指令的代碼只是做生意的成本，所以如果可能的話，應該充分考慮是什麼使得用戶體驗更好。