On Mar 9, 2010, at 9:35 AM, Ivan Lazar Miljenovic wrote:
And further... If I do want to use an interactive program which needs input, how do I send ctrl-d or ctrl-c? tail -f needs ctrl-c (or I need to kill the process)
You want Ctrl-d in Unix-based OSs and Ctrl-z in Windows: http://en.wikipedia.org/wiki/End_of_File . Ctrl-c kills a program.
The statement about UNIX is not quite right. UNIX has *NO FIXED END-OF-FILE CHARACTER*. Strictly speaking, it doesn't have an end-of-file character at all. What the UNIX terminal driver (and interfaces that emulate it) has is a "send this line now with no terminator" character. abcd<EOF> sends "abcd" to the program sans \n ab<EOF> sends "ab" to the program sans \n <EOF> sends "" to the program Program does n = read(0, buffer, sizeof buffer); User types ab<EOF> buffer gets "ab", n gets 2. Program does if (n == 0) handle_eof(); which does nothing. Program calls read again, User types <EOF> buffer gets no data, n gets 0, program tests n against 0 and goes off to do the EOF thing. So the <EOF> character *only* means <EOF> when nothing precedes it on the current line. Why do I write <EOF> rather than ^D? Because nothing in UNIX anywhere says that <EOF> *has* to be ^D, it's just a default. Back in the old V6 days, I saw no more reason to stick with that default than I saw to stick with the default of '#' for character erase and '@' for line kill. I've been using ^Z for <EOF> in UNIX longer than Windows (or DOS before it) has _existed_. If you want to know what character to send for end-of-file when communicating with a UNIX system, use stty(1) to find out what the <EOF> character actually is. Insisting on ^D is not just wrong, it's rude.