What sets a child’s STDERR, STDOUT, and STDIN

It's been available on Linux back into its prehistory. It is not POSIX, although many actual shells (including AT&T ksh and bash) will simulate it if it's not present in the OS; note that this simulation only works at the shell level (i.e. redirection or command line parameter, not as explicit argument to e.g. open()). That said, it should be available on most commercial Unix systems, one way or another (sometimes it's spelled /dev/fd/N for various integers N, but most systems with that will provide symlinks as Linux and *BSD do).

I was able to figure it out using strace -f and writing a small proof of concept in C.

It appears that bash just manipulates file descriptors in the child process before calling execve as I thought.

Here's how ls -la > diroutput.log works (roughly):

• bash calls fork(2)
• forked bash process sees the output redirection and opens the file diroutput.log using open(2).
• forked bash process replaces the stdout file descriptor using the dup2(2) syscall
• bash calls execve(2) to replace it's executable image with ls which then inherits the already setup stdout

The relevant syscalls look like this (strace output):

6924  open("diroutput.log", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 
6924  dup2(3, 1)                        = 1 
6924  close(3)                          = 0 
6924  execve("/bin/ls", ["ls", "-la"], [/* 77 vars */]) = 0