Win32 process spawning, POpen and Hugs, revisited
David Roundy
droundy at abridgegame.org
Wed Mar 17 07:40:54 EST 2004
On Wed, Mar 17, 2004 at 12:01:11PM -0000, Simon Marlow wrote:
>
> On a related note, I recently implemented a System.Process library on
> Unix. Source code attached. The Windows implementation should be
> relatively straightforward. Porting it to Hugs will require
> System.Posix.forkProcess, but I don't see any great difficulties there.
...
> I think this is a good platform-independent abstraction for process
> management. What do others think?
Looks pretty good to me. I'm currently using doing all my forking in C,
since that seems the "easiest" way to go about it, particularly since I
need to do it on both windows and POSIX systems (which I accomplish via
#ifdefs). But this is all very nasty code that I'd like to get rid of (or
more likely, nest in another layer of #ifdefs to deal with old versions of
ghc...).
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), but others (some
versions of vi) will fail if their stdin and stdout correspond to a tty.
It would be nice to be able to run "user-interactive" commands such as text
editors in a safe and consistent manner. 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? If the
process changes the buffering of stdin, will that change it for me?
Enquiring minds want to know! :)
--
David Roundy
http://www.abridgegame.org
More information about the Libraries
mailing list