[Haskell-cafe] Re: Bug in runInteractiveProcess?

Donn Cave donn at drizzle.com
Wed Oct 17 00:39:29 EDT 2007

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  
on Microsoft Windows.  I sure wouldn't know.  Does a process even  
pipe file descriptors?

Or pseudo-ttys - or does it even have them?  A design with a two or  
pipe connection like this is asking for trouble - begging for it,  
with a name like
`runInteractiveProcess' - because most of the commands that you might  
will block-buffer output, confounding the application that expects to  
a dialogue with a forked command.  Pseudo-ttys are pipe-like devices  
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 at drizzle.com

More information about the Haskell-Cafe mailing list