背景
如果我们大多数人都同意过滤器和管道是 Unix 系统的基础。
管道和过滤器是非常强大的工具。几乎所有 Unix 实用程序默认都使用标准输入和输出流，以便可以在管道中使用它们。
它是 Unix 中实用程序运行的约定标准输入和标准输出如果没有指定其他输入/输出文件。
grep、as、sed、tr、perl、sort、uniq、bash、cmp和cat许多其他都是遵循此约定的实用程序。
但许多编程实用程序已经放弃了这一约定。
读取输入
最明显的例子是cc（C 编译器）。
如果您cc不带参数调用，您会收到以下消息：
ryvnf:~$ cc
cc: fatal error: no input files
compilation terminated.
这不是唯一的例子：
ryvnf:~$ yacc
/usr/bin/bison: -y: missing operand
Try '/usr/bin/bison --help' for more information.
较低级别的实用程序，例如asread标准输入默认情况下。我不知道这是为什么。
写入输出
这也适用于输出。
cc默认情况下将其可执行代码输出到a.out。解析器生成器yacc将其生成的解析器输出到y.tab.c.
对我来说，默认情况下使用标准输入/输出流是有利的，因为这样您就可以轻松连接各种实用程序。就像这个管道，它一次性将 yacc 解析器编译为可执行代码，而不生成中间文件，例如y.tab.c：
yacc parser.y | cc -o parser
我的问题
为什么编程实用程序不像许多其他 Unix 实用程序那样默认使用标准流？
不使用的动机是什么标准输入流默认情况下这些实用程序？
笔记我知道你可以cc阅读标准输入通过使用cc -x c -。这是可行的，但我的问题仍然是为什么它默认情况下不这样做。
答案1
管道不适用于源代码，因为您无法处理输入的输入。您需要在处理开始之前加载整个文件。当您需要多个文件进行编译（例如 .h 文件）时，情况会变得更糟。如果您从标准输入读取数据，则需要使用某种方法来流式传输所有需要的文件，以指定您通过管道输入的文件之间的文件中断。问题从此开始增长。
管道背后的想法是，它将是一系列简单的任务。编译代码是不是这是一项简单的任务，因此它从未被设计为管道的一部分。管道理论还指出，管道中进程之间的所有通信都应该采用纯文本形式，以促进各个组件的可移植性。根据定义，cc或yacc或或编译代码中涉及的任何其他内容的输出ld是不适合模型的二进制数据。