為什麼某些實用程序在選項之前解析操作數？

根據幾個 來源，UNIX 實用程序指南指定操作數應始終在選項之後處理：

utility_name[OPTIONS][operands...]

眾所周知，一些較舊的 UNIX 實用程序並沒有完全遵循這些約定find，例如curl <url>.

我想知道這是否有充分的理由，以及社區對此的普遍共識是什麼。

通常的約定是參數總是跟隨選項。第一個非選項（命令行上第一個不以 開頭的字元串-）終止選項並開始參數。

一些工具，特別是建構工具（編譯器、連結器），總是違背這個約定。您注意到的另一個例子是find. 有時這樣做是因為選項在它們出現的命令行上生效，因此您需要一種方法來指定選項之前和之後的參數，其中只有當參數出現在選項之後時，該選項才適用於該參數.

此約定允許您編寫一個包含如下行的 shell 腳本：

rm foobar ${more_things_to_remove}

…並保證rm即使 shell 變數more_things_to_remove具有像“ -rf”這樣的討厭值，您也不會意外地向命令添加選項。

該約定早於使用特殊選項--終止選項處理的最新約定。--是明確標記選項結束的更好方法：

rm -- foobar ${more_things_to_remove}

# and it works even if you don't need to delete something called "foobar":
rm -- ${more_things_to_remove}

所以最近（最近，我的意思是這已經做了很多很多年了）更多的命令行解析器似乎已經朝著打破早期慣例的方向發展，並允許選項和參數明顯地在任何地方混合（始終受制於--強制結束選項），即使它們沒有像編譯器和其他一些工具那樣打破約定的任何特殊理由。

就我個人而言，我永遠不知道哪些實用程序仍然遵守約定，哪些不遵守約定，所以我總是像以前一樣將選項放在參數之前，當我看到其他人的工作程式碼以相反的順序執行時，我有點驚訝！

引用自：https://unix.stackexchange.com/questions/183646