Shouldn't System.Process.runInteractiveCommand close inherited descriptors above 2?

[Tomasz Zielonka]

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