"Bryan O'Sullivan"
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 http://www.scsh.net/docu/html/man-Z-H-4.html#node_sec_3.2.4 for details. 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 important.) (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.) -m