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

Mike Gunter m at
Mon Jun 4 17:03:34 EDT 2007

"Bryan O'Sullivan" <bos at> writes:

> 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.

I like the way Scsh handles this.  On exec, it closes file descriptors
for ports (Scheme's Handles) that haven't had their file descriptor
"revealed" (i.e., been the argument to handleToFd or the return value
from fdToHandle) .  See for

If the program doesn't know what file descriptor corresponds to a
handle, it's hard to see what good could come from keeping the
descriptor open across an exec().  (I suppose you could exec() then
find out and communicate the descriptor afterward--but I doubt that's

(Scsh also uses the revealed file descriptor information to support
shifting around the unrevealed descriptors of ports when that
descriptor is the target of a dupTo.)


More information about the Libraries mailing list