On Mon, Jun 04, 2007 at 11:03:30AM -0700, Bryan O'Sullivan wrote:
Tomasz Zielonka wrote:
So the question is: shouldn't runInteractiveCommand / runInteractiveProcess close descriptors greater then 2 in the child process?
No. What your colleague experienced is normal Unix behaviour with about 30 years of history under its belt. Having Haskell do something different would be the surprise here.
OK, so it's not a good idea to close fds by default. But if I want to? Sometimes there are good reasons to do so.
You can mark file descriptors that you don't want shared with fcntl's F_SETFD command, and FD_CLOEXEC:
noExec :: Handle -> IO () noExec h = do fd <- handleToFd h setFdOption fd CloseOnExec True
Interesting, I didn't know about such option. It might help in this situation, but in general it would be unnatural. It seems more natural to specify which descriptors you want passed through a particular exec - because you should know that (I can imagine some counter-examples, but I'm not sure they would be a good idea anyway). Additionaly, in a complex application you may want a particular descriptor to be passed through one exec(), and not passed through another. The other solution to our problem is to create a wrapper program that will close all unneccesary descriptors and then execute the actual program. I think that's what we are going to do. So my initial question changes to: would it be useful to have an extended version of runInteractiveProcess with options for using non-standard behaviour and things like setsid(2)? Did anyone other than us wanted such functionality? I guess System.Process wouldn't be a good place for such function, because this module is meant to be portable across different OSes? Best regards Tomek