Shouldn't System.Process.runInteractiveCommand close inherited
descriptors above 2?
tomasz.zielonka at gmail.com
Mon Jun 4 15:05:12 EDT 2007
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
> 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?
More information about the Libraries