Почему 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 -xc - . Это работает, но мой вопрос остается, почему он не делает этого по умолчанию.

  • piping ssh к сценарию оболочки и не видеть stdin echo
  • Могу ли я подключать stdout на одном сервере к stdin на другом сервере?
  • Как stdin обрабатывается в этом сценарии bash?
  • Текст заменяет буквально * все * экземпляры строки через stdin, stdout
  • В сценарии проверьте, не поступает ли стандартный ввод из файла или канала
  • Предоставлять строки, хранящиеся в файле, в виде списка аргументов для команды?
  • Есть ли способ ввода «tee» в программу или скрипт?
  • Можно ли управлять xterm (или, в частности, процессом, который начал xterm) из другого процесса?
  • One Solution collect form web for “Почему cc (компилятор C) и подобные утилиты по умолчанию не используют стандартные потоки?”

    Трубопроводы не работают для исходного кода, потому что вы не можете обрабатывать ввод по мере его поступления. Перед загрузкой необходимо загрузить весь файл. Это становится еще хуже, когда вам нужно несколько файлов для компиляции (например, файлы .h). Если вы читали stdin, вам нужно было бы передавать все необходимые файлы с помощью некоторого метода определения разрывов файлов между файлами, в которые вы вставляете сообщения. Проблемы просто растут оттуда.

    Идея трубопровода заключалась в том, что это будет серия простых задач. Компиляция кода НЕ является простой задачей, поэтому он никогда не был предназначен для конвейера. Также теория трубопроводов говорит, что вся связь между процессами в трубопроводе должна быть в виде простого текста, чтобы облегчить переносимость отдельных компонентов. По определению вывод cc или yacc или ld или что-либо еще, участвующее в компиляции кода, представляет собой двоичные данные, которые не соответствуют модели.

    Linux и Unix - лучшая ОС в мире.