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

Tomasz Zielonka tomasz.zielonka at gmail.com
Mon Jun 4 14:11:55 EDT 2007


On Mon, Jun 04, 2007 at 09:17:44AM -0700, Adam Langley wrote:
> On 6/4/07, Tomasz Zielonka <tomasz.zielonka at gmail.com> 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]

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

BTW, I've used tcpclient :-)

Best regards
Tomek


More information about the Libraries mailing list