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