Background
If think most of us agree that filters and pipes are the very foundation of Unix systems.
Pipes and filters are very powerful tools. Almost all Unix utilities use the standard input and output streams by default to make it possible to use them within pipelines.
It is a convention for utilities within Unix to operate standard input and standard output if no other input/output files have been specified.
grep
, as
, sed
, tr
, perl
, sort
, uniq
, bash
, cmp
, cat
and many others are all utilities that follow this convention.
But many programming utilities have abandoned this convention.
Reading input
The most obvious example of this is cc
(the C compiler).
If you invoke cc
with no arguments you get this message:
ryvnf:~$ cc
cc: fatal error: no input files
compilation terminated.
This is not the only example of this:
ryvnf:~$ yacc
/usr/bin/bison: -y: missing operand
Try '/usr/bin/bison --help' for more information.
Lower-level utilities like as
read standard input by default. I wonder why that is.
Writing output
This also applies to output.
cc
outputs its executable code into a.out
by default. The parser generator yacc
outputs its generated parser to y.tab.c
.
To me using standard input/output streams by default is advantageous because then you can easily connect various utilities. Like this pipe which compiles a yacc parser to executable code in one go without generating intermediate files like y.tab.c
:
yacc parser.y | cc -o parser
My question
Why is it that utilities for programming don't use the standard streams by default as many other Unix utilities do?
What is the motivation for not using standard input streams by default for these utilities?
Note that I am aware that you can get cc
to read standard input by using cc -x c -
. This works but my question remains why it doesn't do this by default.
cc
if standard input/output was used by default. – wefwefa3 Nov 30 '15 at 17:50