On Oct 16, 2007, at 7:31 PM, Brandon S. Allbery KF8NH wrote:
I could dig for official confirmation, but this is my understanding of both POSIX and SUS, and portable C programs generally #define FD_CLOEXEC to 1 if it doesn't already exist, since the value *is* standard even though the name is not.
I find `runInteractiveProcess' in System.Process, in the documentation - not System.Posix.Process. Possibly the C macro is less important than the cross-platform semantics relating to this problem. I.e., what happens on Microsoft Windows. I sure wouldn't know. Does a process even inherit pipe file descriptors? Or pseudo-ttys - or does it even have them? A design with a two or three-way pipe connection like this is asking for trouble - begging for it, with a name like `runInteractiveProcess' - because most of the commands that you might invoke will block-buffer output, confounding the application that expects to conduct a dialogue with a forked command. Pseudo-ttys are pipe-like devices that won't be block-buffered, and they're really the only more or less reliable way to have an `interactive' I/O exchange with another command that wasn't written specifically to support this. As for closing file descriptors explicitly - if I remember right what I've seen in the NetBSD source, the UNIX popen() implementation may years ago have closed all file descriptors, but now it keeps track of the ones it created, and only closes them. I think that's the way to go, if closing fds. Donn Cave, donn@drizzle.com