The "loop and a half"

[Gregory Ewing]

bartc wrote:
> This preprocesses the code and shows the result. Typical programs will 
> have many thousands of lines of output, but it just dumps it to the 
> console. You /have/ to use '>' to use it practically (Windows doesn't 
> really have a working '|' system.)

This may be why you're having trouble grokking unix. The
primary purpose of the unix convention of reading from stdin
and writing to stdout by default is to make it easy to use
programs in pipelines. If you haven't experienced that way
of working, you may not appreciate how useful it can be.

> BTW if I try:
> 
>  > gcc <program.c
> 
> it doesn't work (this on Linux). What happened to the generic solution?

I agree that the C compiler is unusual in that respect. The
reason may be that it relies on filename suffixes to figure out
what to do with its inputs: if it's .c, compile it; if it's
.s, assemble it; if it's .o, link it; etc. It wouldn't know
what to do with something fed into stdin.

There may be ways to tell it, though. Stack Overflow suggests:

    flex -t lexer.l | gcc -x c -c -o lexer.o -

-- 
Greg