Hello! My coworker just experienced a strange situation: a network connection wasn't automatically closed when the process finished. It was because a child process unneccesarily inherited this connection's descriptor. So the question is: shouldn't runInteractiveCommand / runInteractiveProcess close descriptors greater then 2 in the child process? The following program shows this behaviour on Linux: import System.Process import System.IO main = do h1 <- openFile "/etc/passwd" ReadMode (_, pout, _, phandle) <- runInteractiveCommand "ls -l /proc/self/fd" hGetContents pout >>= putStr waitForProcess phandle hClose h1 The result: tomekz@tomekz:~/devel/haskell/interactive-process-filedes$ ./IP total 5 lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 0 -> pipe:[22830] l-wx------ 1 tomekz tomekz 64 2007-06-04 11:50 1 -> pipe:[22831] l-wx------ 1 tomekz tomekz 64 2007-06-04 11:50 2 -> pipe:[22832] lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 3 -> /etc/passwd lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 4 -> /proc/13687/fd As you can see, the "ls" process inherits the file descriptor to /etc/passwd from the Haskell program process. This is in GHC 6.6. I wonder if anyone explicitly wants such behavior, but even if so, IMHO the default behaviour should be to close such descriptors. I think the current situation could even cause some security problems. Best regards Tomek