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 -- https://mail.python.org/mailman/listinfo/python-list
