為什麼 stdin 輸入具有類似選項的輸入並不常見，而命令行參數卻很常見？

POSIX 和 GNU 有它們的選項語法風格。對於我見過的所有命令，它們都接受類似選項的輸入作為命令行參數。

程序從標準輸入接受類似選項的輸入（並因此用於getopt解析類似選項的標準輸入）是不常見的嗎？就像是：

$ ls -l 
-rw-rw-r-- 1 t t 31232 Jan  7 13:38 fetch.png
-rw-rw-r-- 1 t t 69401 Feb  6 14:35 proxy.png
$ myls
> -l  
-rw-rw-r-- 1 t t 31232 Jan  7 13:38 fetch.png
-rw-rw-r-- 1 t t 69401 Feb  6 14:35 proxy.png
> -l fetch.png
-rw-rw-r-- 1 t t 31232 Jan  7 13:38 fetch.png

為什麼 stdin 輸入具有類似選項的輸入並不常見，而命令行參數卻很常見？

從表達能力的角度來看（類似於正常語言與上下文無關語言），非選項之類的輸入和選項之類的輸入是否等效？

讓我們不要強調 shell 擴展，因為我們從不期望（或不需要）像 shell 擴展這樣的事情發生在標準輸入輸入（非選項之類）上。

謝謝。

類似輸入的非選項類似問題：https ://stackoverflow.com/questions/54584124/how-to-parse-non-option-command-line-arguments-and-stdin-inputs （由於沒有響應和否決票。但如果您有足夠的聲譽，仍然可以訪問）

tl;dr 這與想要ls在腳本（1、2）中使用非常相似，僅在必要時引用，或者跨越流（這幾乎就是字面上的意思，通過使用 stdin 來處理兩個完全正交的事情）。這是個壞主意。

這種方法存在幾個問題：

1. 您的工具必​​須處理shell 已經為您

處理的所有**擴展：**

• 大括號展開
• 波浪擴展
• 參數和變數擴展
• 命令替換
• 算術展開
• 分詞
• 文件名擴展，包括@StephenHarris 指出的萬用字元

2. 如果您的工具不處理任何擴展（正如您所建議的那樣，與您給出的範例相反，顯然必須進行分詞才能不將-l fetch.png其視為單個參數）您將不得不向開發人員詳細解釋為什麼沒有-l "$path"，-l ~/Downloads並-l 'my files'按照他們的期望行事。
3. 當您的工具處理擴展的方式與 shell不同時（它會這樣做，因為 shell 處理擴展的方式不同，沒有人能負擔得起檢測您正在執行的 shell 並永遠支持所有它們），您剛剛添加了一個新語法，需要每個使用您的工具的人都可以學習、記住和使用。
4. 標準輸入不再只是工具輸入。基於**The Unix Philosophy，**它不能再與其他工具一起簡單地工作，因為那些其他工具必須做一些特殊的事情才能將輸入傳遞給您的工具。
5. 每個主要工具都已經使用了一個約定。就可用性而言，以這種基本方式打破正常將是一個非常糟糕的主意。
6. 對於任意輸入，混合選項和輸入不能安全地完成，除非您在編碼或轉義其中一個時遇到相當大的額外麻煩。

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