Unfortunately, I don't know of a good write-up of how the kernel actually deals with file descriptors, aside from the man pages for the various syscalls you're

Unfortunately, I don't know of a good write-up of how the kernel actually deals with file descriptors, aside from the man pages for the various syscalls you're using. From the kernel's perspective, there's nothing special about file descriptors 0, 1, and 2. The shell did the same pipe/fork/dup2/exec procedure as your code when it launched your program, and hooked the other end of the pipes to the terminal. When you call fork(), both processes keep all of their open file descriptors, which is why you have to close the ones you're not going to use with either close() or dup2(). If stdout or stderr is already attached to the correct destination when fork() is called, it's perfectly acceptable to leave them alone. Read-mode file descriptors (like stdin) are more problematic if they're used concurrently by multiple processes. Only one of the processes will read any given piece of data that was written into the pipe, so you need to coordinate the reads between the processes somehow.