
On Mon, Jun 04, 2007 at 09:17:44AM -0700, Adam Langley wrote:
On 6/4/07, Tomasz Zielonka
wrote: So the question is: shouldn't runInteractiveCommand / runInteractiveProcess close descriptors greater then 2 in the child process?
This is actually a pretty subtle area of POSIX (and probably something that was badly designed in the first place). Inheriting of fds is often surprising, but if the runtime were to close everything > 2, then how would you be able to pass one to a child process? There are many instances where you want to do this[1].
I agree there are some such instances, but IMO they constitute only a small part of all uses in code. In most cases when you use these functions, you don't want such behavior. If you are lucky, it makes no harm and you simply don't care. I wonder if there is any Haskell program using this possibility... (please come forward :-)) If you use those functions and you want the child process to inherit some additional fds, you need to control file descriptors (know them, change them) - this may force you to abandon or break Haskell's Handle abstraction. Well, at least you have those functions in System.Posix: fdToHandle :: Fd -> IO GHC.IOBase.Handle handleToFd :: GHC.IOBase.Handle -> IO Fd dupTo :: Fd -> Fd -> IO Fd dup :: Fd -> IO Fd
Maybe there needs to be an additional argument which contains fd numbers which should be passed down?
I forgot to propose this explicitly, but this is the spirit of my suggestion for closing by default. OTOH, adding new parameters to library functions is not without cost. This could also be a new function, perhaps armed with options for many such subtleties - like starting a new process group, etc. It could be a list of options, eg. runInteractiveProcessWithOpts ... [CloseOtherFiles, SetSessionID]
BTW, I've used tcpclient :-) Best regards Tomek