Por que o cc (o compilador C) e utilitários semelhantes não usam streams padrão por padrão? [fechadas]

Question

Antecedentes

Se acharmos que a maioria de nós concorda que filtros e canos são a base dos sistemas Unix.

Tubos e filtros são ferramentas muito poderosas. Quase todos os utilitários Unix usam os fluxos de entrada e saída padrão por padrão para possibilitar sua utilização nos pipelines.

É uma convenção para utilitários dentro do Unix operar entrada padrão e saída padrão se nenhum outro arquivo de entrada / saída tiver sido especificado.

grep , as , sed , tr , perl , sort , uniq , bash , cmp , cat e muitos outros são todos utilitários a seguir esta convenção.

Mas muitos utilitários de programação abandonaram esta convenção.

Entrada de leitura

O exemplo mais óbvio disso é cc (o compilador C).

Se você invocar cc sem argumentos, receberá esta mensagem:

ryvnf:~$ cc
cc: fatal error: no input files
compilation terminated.

Este não é o único exemplo disso:

ryvnf:~$ yacc
/usr/bin/bison: -y: missing operand
Try '/usr/bin/bison --help' for more information.

Utilitários de nível inferior, como as , lêem entrada padrão por padrão. Eu me pergunto por que isso é.

Escrevendo saída

Isso também se aplica à saída.

cc exibe seu código executável em a.out por padrão. O gerador de analisadores yacc envia seu analisador gerado para y.tab.c .

Para mim, usar fluxos padrão de entrada / saída por padrão é vantajoso porque você pode facilmente conectar vários utilitários. Como este pipe que compila um analisador yacc para código executável de uma só vez, sem gerar arquivos intermediários como y.tab.c :

yacc parser.y | cc -o parser

Minha pergunta

Por que os utilitários para programação não usam os fluxos padrão por padrão, como muitos outros utilitários Unix fazem?

Qual é a motivação para não usar fluxos de entrada padrão por padrão para esses utilitários?

Note que estou ciente de que você pode obter cc para ler entrada padrão usando cc -x c - . Isso funciona, mas a minha pergunta permanece porque ele não faz isso por padrão.

    

Answer 1

Os pipelines não funcionam para o código-fonte porque você não pode processar a entrada à medida que ela entra. Você precisa do arquivo inteiro carregado antes do início do processamento. Isso fica ainda pior quando você precisa de vários arquivos para compilação (arquivos .h, por exemplo). Se você estivesse lendo stdin, você precisaria transmitir em todos os arquivos necessários algum método de especificar quebras de arquivos entre os arquivos que você inseriu. Os problemas crescem a partir daí.

A ideia por trás do pipeline era que seria uma série de tarefas simples. A compilação de código é NOT uma tarefa simples e, portanto, nunca foi projetada para fazer parte de um pipeline. Também a teoria de oleodutos disse que toda a comunicação entre os processos no pipeline deve estar em texto simples para facilitar a portabilidade de componentes individuais. Por definição, a saída de cc ou yacc ou ld ou qualquer outra coisa envolvida na compilação de código são dados binários que não se encaixam no modelo.