Win32 process spawning, POpen and Hugs, revisited

[Glynn Clements]

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
stdin/stdout.

> 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
pseudo-tty?

> 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"
it.

> 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
programs".

> 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>