EOF (stdin) in Ubuntu 10.04 Lucid Lynx

[gnometorule]

A friend learning C using KR asked me a question that pointed out a behavior that confuses me too. When going over the early book examples (e.g., ch. 1.5.1) in which you just mirror input and output such as (straight from book)....



#include <stdio.h>

main(){

int c;

while ( (c = getchar()) != EOF)
putchar(c);

}
...you need to hit twice ^d to get out of the loop. The effect is as if one ^d only was hit. Any explanations?

[Bachstelze]

I only need to hit ^D once here... But the behavior of hitting ^D may differ in different terminal emulators or even different shells. Contrary to popular belief, ^D does not send EOF.

[gnometorule]

Ah. So it could be just a terminal emulation oddity that one, for practical purposes, accepts and ignores? Or is there another way to communicate 'EOF' to a stdin stream?

[papibe]

Does it get stuck if you use files? Something like this:

./yourprogram < afile > otherfile
Regards.

[Bachstelze]

Basically, you do not "communicate" EOF to the process: EOF is by definition not a character, it is the name given to the value getchar will return when it can't read any character. So anything that causes the input to stop will make getchar return EOF.

[gnometorule]

Good idea. Your piping suggestion copies the input file perfectly fine to the output file.

I played with it more on my Toshiba (grub Ubuntu/W7), and also under Lucid Lynx. For stdin, the behavior in slightly more involved (slightly) programs playing with stdin gets weird while more or less on target.

In sum, I take it as a terminal emulation quirk in this setup affecting only stdin, and am fine with it?

[gnometorule]

@ Bachstelze (nice name, I'm German too while living away from home)

I don't understand how or if that explains an answer to my question though. If it does, kindly try again.

[Bachstelze]

In sum, I take it as a terminal emulation quirk in this setup affecting only stdin, and am fine with it?

Probably. When you use a file as input it's simple: the output ends when all the characters in the file have been read, so there is no ambigity as to when getchar will return EOF. When you're reading from a terminal, however, it basically depends on when exactly your terminal "cuts" the input stream. It rarely really matters, though, whether you have to press ^D once or twoce.

[gnometorule]

Thanks everyone. Closing this now.

[Arndt]

Thanks everyone. Closing this now.

Sorry for continuing a closed thread, but I think the situation when you have to type ^D twice is when you did not just enter a newline.

Also, I think it's the terminal (pty) driver that has this behaviour, not the terminal emulator. It may be documented in some manual page in section 7.