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

-----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Tomasz Zielonka Sent: Monday, June 04, 2007 2:12 PM To: Adam Langley Cc: libraries@haskell.org Subject: Re: Shouldn't System.Process.runInteractiveCommand close inherited descriptors above 2? 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 :-)) I do rely on this behavior, and I use it in applications that are commercially deployed, so I would argue strongly against changing the default behavior w.r.t. this issue. A new function which allows the parent to control which handles are available to the child is an excellent idea. I would be in favor of an argument (to runInteractiveCommandExtended, or whatever) which is a list of handles that the child process can use. The function can then close handles that are not part of the list. I guess you would need to use (handleToFd handle) to map the handles in the list to the integer file descriptors. This is certainly esthetically unpleasing, but as far as I can see it would work. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface 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]

[1] http://cr.yp.to/ucspi-tcp/tcpclient.html

BTW, I've used tcpclient :-) Best regards Tomek _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries