How to emit EOF to a file descriptor (while keeping it open)?

Question

What code can my program call to behave similarly to pressing Ctrl+D in a terminal? That is, to cause a read function called on STDIN to return 0 in a child process, but without having this "STDIN" file descriptor closed in the parent process?

I'm trying to understand how the EOF condition is communicated to a process in Linux.

It appears read returning 0 is only advisory, and you can actually carry on reading after encountering such an EOF condition. Consider the following program:

#include <unistd.h>
#include <stdio.h>

void terminate_buf(char *buf, ssize_t len)
{
    if(len > 0) {
        buf[len-1] = '\0';
    } else {
        buf[0] = '\0';
    }
}

int main()
{
    int r;
    char buf[1024];

    while(1) {
        r = read(0, buf, 1024);
        terminate_buf(buf, r);
        printf("read %d bytes: %s\n", r, buf);
    }

    return 0;
}

If you compile (gcc -o reader reader.c, assuming you named it reader.c) and run this program in a terminal, then press Ctrl+D, then input foobarEnter, you will see this:

$ ./reader 
read 0 bytes: 
foobar
read 7 bytes: foobar

indicating it's totally possible to read meaningful data after an EOF event has occurred. You can press Ctrl+D multiple times on a line of its own, followed by some text, and reader will carry on reading your data as if nothing had happened (after printing "read 0 bytes: " for each press of Ctrl+D). The file descriptor remains open.

So what's going on here and how can I replicate this behaviour? How can I cause a child process to see some data after seeing EOF? Is there a way to do it using just regular file I/O (and perhaps ioctls), or do I need to open a pty? Calling write with a count of 0 doesn't seem to work, read doesn't even return on the other end. What is EOF, really?

Answer 1

Ctrl-D (0x04) is mapped to EOF by a terminal device. If you are reading from a pipe or file, that will not happen.

echo -e "a\x04b" | cat

or

echo -e "a\x04b" | hd

If the first program in the pipe is reading from a terminal and you want to ignore the mapped EOF, you can, for example, change the terminal behaviour:

stty eof -

And Ctrl-D will no longer work. Or you can change the whole line discipline with:

stty raw

And read it as you would read a file, with no conversions.

You could use the EOF character to send multiple files, provided that none of those files contain that character. A pty would do it.

But you might be better off with established solutions though, like MIME multipart, things like zmodem, or archiving to the pipe (for example here the second tar lists the files the first one archived: tar cf - *txt | tar tf -).

Answer 2

The thing is that there really is no such thing as an "EOF condition". By convention, a read returning 0 is interpreted as the end of a file, but as you have seen, you can go on reading. Additional reads may return 0 again, or they can return more data, if some other process has written to the file in the mean time.

Not even a Ctrl-D from the terminal has a special "EOF" signalling property. What it really does is return the current line input to the process, just like pressing the Enter key does, but with the difference that no newline is appended. If Ctrl-D is pressed as the first input on a line, i.e. an empty line, then zero characters are returned, which is, again by convention, interpreted as an "EOF".

It is up to the process invoking the read system call how to interpret a return value of 0 from read.