[dllthomas]

Copying file descriptors is genuinely what's going on, so understanding it that way always works.

Edited for clarity:

The way file descriptors work is that the kernel maintains, for each process, a table mapping from numerical file descriptors to structures describing the open file/socket/device associated with that descriptor.

When the shell is setting up to spawn a new process (or subshell, for that matter), it processes the redirections in order, left to right. For redirections of the form "A>&B" this is a call to dup2(B, A), which has the kernel copy the entry in the table at B over the entry at A.

Incidentally, you will note the direction of the symbol doesn't matter when cloning file descriptors: 5>&7 and 5<&7 mean the same thing - you're just copying a file descriptor. It does matter when opening a file, as the file will be opened for reading or writing before before being dup2'ed over the requested descriptor. Having said that, of course use the correct symbol - it's good documentation.

[wethesheeple]

Thanks for the this. In my opinion, there's too little written about passing fd's (use of dup2). It seems like a technique that is more useful than just as part of shell redirection. Safer than popen()?

[dllthomas]

I'm pretty sure popen is just a wrapper around this stuff. It's basically,

pipe: get two fds connected by a pipe

fork: create a child process

dup2: move the read fd of the pipe to 0 (stdin) in the new process

exec: run the program in the child process

There's some cleanup but that's the gist - popen isn't a syscall (or reasonably close to one), so must necessarily rely on other stuff to get its work done where it actually interfaces with the kernel.

[wethesheeple]

That makes perfect sense. It's the fork+exec that makes it dangerous (e.g. in the CGI context). This is something I've been wondering about and you have just provided a jolt of clarity. Many thanks, again.

[dllthomas]

Happy to help :)