为什么 stdin 输入具有类似选项的输入并不常见，而命令行参数却很常见？

Question

POSIX 和 GNU 有其选项的语法样式。对于我见过的所有命令，它们接受类似选项的输入作为命令行参数。

程序接受来自 stdin 的类似选项的输入（因此用于getopt解析类似选项的 stdin 输入）是否不常见？就像是：

$ 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 扩展这样的事情发生在 stdin 输入上（类似非选项）。

谢谢。

对于像输入这样的非选项的类似问题：/sf/ask/3820888711/（该帖子由于没有回应而被删除，并且否决票。但如果您有足够的声誉，仍然可以访问）

Answer 1

lstl;dr 这与想要在脚本（1 , 2）中使用非常相似，仅在必要时引用，或跨流（这几乎就是字面上的意思，通过使用 stdin 来处理两个完全正交的事物）。这是一个坏主意。

这种方法存在几个问题：

1. 您的工具必​​须处理shell 已经为您处理的 所有扩展：
   • 大括号扩展
   • 波形符扩展
   • 参数和变量扩展
   • 命令替换
   • 算术展开
   • 分词
   • 文件名扩展，包括@StephenHarris 指出的通配符
2. 如果您的工具不处理任何扩展（正如您所建议的，与您给出的示例相反，该示例显然必须进行分词才能不将其视为-l fetch.png单个参数），您将不得不向开发人员详细解释为什么没有-l "$path"，-l ~/Downloads并-l 'my files'做他们期望的事情。
3. 当你的工具处理扩展的方式与 shell 不同时（它会这样做，因为 shell 处理扩展的方式不同，没有人能够检测到你正在运行的 shell 并永远支持所有这些），你刚刚添加了一个新的语法，它需要供使用您的工具的每个人学习、记住和使用。
4. 标准输入不再只是工具输入。基于Unix 哲学，它不能再与其他工具一起工作，因为其他工具必须做特殊的事情才能将输入传递给您的工具。
5. 每个主要工具都已经使用了一个约定。就可用性而言，以如此根本的方式打破惯例将是一个非常糟糕的主意。
6. 对于任意输入，混合选项和输入不能安全地完成，除非您花费相当大的额外麻烦来编码或转义其中之一。