Win32 process spawning, POpen and Hugs, revisited

[David Roundy]

On Thu, Mar 18, 2004 at 05:10:04PM +0000, Glynn Clements wrote:
> 
> David Roundy wrote:
> > but others (some versions of vi) will fail if their stdin and stdout
> > correspond to a tty.
> 
> Correspond, or don't correspond?

Ineed, I meant to say "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 thinking of suspending the parent.  Certainly having two programs try
to read from stdin would be a nightmare.

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

Hmmmm.  So either we'd have to dup stdin and stdout before passing them, or
hope that the program doesn't close them (and the duping *could* be done by
runInteractiveProcess, if we wanted it to actively support this usage).

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

Fortunately, as long as the *called* program behaves nicely (i.e. doesn't
leave the tty in a different state than it started in), this shouldn't be a
problem.

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

It was an actual request for information.  I'd really love to be able to
just open an editor to let the user edit a file and have it just work, and
currently I have no way of doing that which works with vi.  On the other
hand, if the answer is "No, don't pass stdin and stdout to
runInteractiveProcess", it would still be a very useful call, it just
wouldn't solve my vi problem.
-- 
David Roundy
http://www.abridgegame.org