I didn't (yet) receive Simon's original message, but I did look in the archive [1], where the source code attachment shows up as a "non-text" .obj file. So my comment may be based on incomplete information. Is "forkProcess" in the sense of a Unix fork? If so, this is something that is difficult to do cleanly on Windows -- normally, it requires the full Cygwin emulating environment, which as far as I'm concerned is a killer for deploying applications. Theoretically, Windows NT kernel does have a facility to "clone" an entire process, complete with address space contents, but, as far as I'm aware this functionality is not exposed by the Win32 API. (This is a shame, because the Unix fork model is extraordinarily elegant, and simplifies a whole raft of process-creation issues, but Windows is what we have to live with.) #g -- [1] http://www.haskell.org//pipermail/libraries/2004-March/001832.html At 07:40 17/03/04 -0500, David Roundy wrote:
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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact