為什麼 cc（C 編譯器）和類似的實用程序預設不使用標準流？
背景
如果認為我們大多數人都同意過濾器和管道是 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.較低級別的實用程序，例如預設
as讀取標準輸入。我不知道這是為什麼。寫入輸出
這也適用於輸出。
cc預設輸出其可執行程式碼a.out。解析器生成yacc器將其生成的解析器輸出到y.tab.c.對我來說，預設使用標準輸入/輸出流是有利的，因為這樣您就可以輕鬆連接各種實用程序。就像這個管道一樣，它可以一次性將 yacc 解析器編譯為可執行程式碼，而無需生成中間文件，例如
y.tab.c：yacc parser.y | cc -o parser我的問題
為什麼程式實用程序不像許多其他 Unix 實用程序那樣預設使用標準流？
這些實用程序預設不使用標準輸入流的動機是什麼？
cc請注意，我知道您可以使用cc -x c -. 這可行，但我的問題仍然是為什麼預設情況下它不這樣做。
管道不適用於原始碼，因為您無法在輸入輸入時對其進行處理。您需要在處理開始之前載入整個文件。當您需要多個文件進行編譯（例如 .h 文件）時，情況會變得更糟。如果您從標準輸入讀取，則需要使用某種方法在您輸入的文件之間指定文件中斷的方法來流式傳輸所有需要的文件。問題只是從那裡開始。
管道背後的想法是它將是一系列簡單的任務。編譯程式碼不是一項簡單的任務，因此它從未被設計為管道的一部分。管道理論還表示，管道中程序之間的所有通信都應該以純文字形式進行，以促進各個組件的可移植性。根據定義，編譯程式碼中涉及的
cc或yacc或ld或其他任何內容的輸出是不適合模型的二進制數據。