Win32 process spawning, POpen and Hugs, revisited
glynn.clements at virgin.net
Thu Mar 18 17:10:04 EST 2004
David Roundy wrote:
> The only thing I'd like to check on that I can't tell about is whether
> passing stdin and stdout to runProcess will behave "correctly". Some
> programs (e.g. gpg) can figure out how to get control of the tty by
> themselves (to ask for passwords in the case of gpg),
Programs which read passwords generally open the controlling TTY,
directly, i.e. open("/dev/tty", O_RDONLY); this is quite distinct from
> but others (some
> versions of vi) will fail if their stdin and stdout correspond to a tty.
Correspond, or don't correspond?
> It would be nice to be able to run "user-interactive" commands such as text
> editors in a safe and consistent manner.
Are you referring to the case where you let the child inherit the
parent's stdin/stdout, and suspend the parent for the duration of the
child (e.g. system("$EDITOR ..."))? Or running the child on a slave
> I'm not clear from your code
> whether there will be a problem with passing stdin and stdout to
> runProcess. If the process closes stdin, will it be closed for me?
I would expect so; once a descriptor is close()d, you can't "unclose"
> If the
> process changes the buffering of stdin, will that change it for me?
*Buffering* involves user-space memory, so it can't be preserved
across an exec() call. However, GHC's hSetBuffering doesn't just set
the buffering; it also messes with the TTY settings. As those are
per-device rather than per-process, any changes would inevitably
affect the child (unless runProcess explicitly undoes the changes when
passed a Handle which corresponds to a TTY).
Realistically, the hSetBuffering misfeature should be discarded if
Haskell is meant to be useful for anything beyond "simple, stupid
> Enquiring minds want to know! :)
In view of the smiley: was this an actual request for information, or
a way of pointing out that you need to define the semantics in order
for the function to be of any real use?
Glynn Clements <glynn.clements at virgin.net>
More information about the Libraries