Win32 process spawning, POpen and Hugs, revisited

[Glynn Clements]

David Roundy wrote:

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

Right; the way that's normally done in C is with system(), plus saving
and restoring the tty state if you've been messing with it (e.g. using
curses; although that won't actually matter for a child program which
itself uses curses, as it will set up the tty itself).

For your purposes, runProcess + waitForProcess is probably the way to
go. Except that runProcess appears to be missing the usual signal
handling. system() ignores SIGINT and SIGQUIT in the parent, and
resets them to their defaults in the child; it also blocks SIGCHLD in
the parent. runProcess may need to do something similar; it should
probably at least reset SIGINT and SIGQUIT in the child, in case they
are ignored in the parent. The parent can set up its own signal
handling, but the only place it can control the child's signal
handling is between the fork() and the exec(), so if runProcess
doesn't do it, it won't get done.

FWIW, runInteractiveProcess isn't what you're looking for. That
explicitly sets up pipes for stdin/stdout/stderr; i.e. it's meant for
running a "slave" process, with the caller providing its input and
consuming its output (like popen(), only more so).

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

I think that I misunderstood you here. If the child process closes the
descriptors, that won't affect the parent, as fork() automatically
duplicates all descriptors. I was referring to the case where the
parent had closed some of the descriptors prior to calling runProcess.

-- 
Glynn Clements <glynn.clements at virgin.net>