4 ms·

Is there a typo: s/genuinely/not geniuinely I guess what you're explaining is the process that happens as the kernel reserves fd's? And when you start your pr

Is there a typo: s/genuinely/not geniuinely I guess what you're explaining is the process that happens as the kernel reserves fd's? And when you start your program there isn't necessarily any guarantee that a particular fd will be available, except for 0,1,2, right?

dllthomas 14y ago
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 14y ago
  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 14y ago
    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.
    - deleted 14y ago
      [deleted]
    - wethesheeple 14y ago
      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 14y ago
        Happy to help :)

dllthomas 14y ago

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 14y ago
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 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - wethesheeple 14y ago
    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 14y ago
      Happy to help :)