[Haskell-cafe] Re: Bug in runInteractiveProcess?

[Donn Cave]

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 at drizzle.com