[Haskell-cafe] Re: Bug in runInteractiveProcess?
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
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
in the NetBSD source, the UNIX popen() implementation may years ago
have closed all file descriptors, but now it keeps track of the ones
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