System.Process

[David Roundy]

On Thu, Jun 17, 2004 at 04:33:15PM +0100, Simon Marlow wrote:
> I've now implemented the System.Process library on Windows too.  It
> needs Ross Paterson's new version of the Win32 library, which can be
> found in CVS under libraries/win32.
> 
> While doing the Windows port I realised that parts of the interface
> didn't work out too nicely, so I have left out createPipe and
> commandToProcess from the interface.  If you think it is imperative to
> have either of these, please yell.

I don't think either is imperative, but noticed that the documentation
refers to createPipe.

> Comments please... perhaps there ought to be some simpler versions of
> the general functions in this library, to cover the more common cases?

While I'm not a fan of the Maybe method of providing optional arguments,
it's hard to see any small set of simpler versions that one could devise.
Having five runProcessX functions doesn't simplify things.  It's probably
simplest to let the users define simpler versions... unless you perhaps
wanted to define a runProcess analog of "system", which differs only in
that it accepts a FilePath and [String] instead of a shell command.

The simpler versions I would use would probably be:

runProcessStringInOut :: FilePath -> [String] -> String -> IO String

(last arguments is stdin and return value is stdout).

runProcessStringIn :: FilePath -> [String] -> String -> IO ExitCode

and the obvious extention

runProcessStringOut :: FilePath -> [String] -> IO String

As you can see, I always want my processes to exit.  I suppose the two
which return strings could do so lazily with the process continuing to run,
but I think I'd rather have them *not* do so, since exit with failure
obviously must trigger an exception, and I'd rather get the exception
synchronously (when I can exit with "process X exited with error code Y")
rather than failing at some later date when I'm consuming a lazy string.
hGetContents is fine and dandy for files, but processes have an annoying
tendancy to fail far more often and for less obvious reasons.

Anyhow, each of the above is trivial to implement using System.Process as
given, and I see no real reason to add them (or others) to System.Process
itself.

> If there are no serious problems, this will be imported into CVS for GHC
> 6.4, and possibly future Hugs/nhc98 releases, if there aren't any
> portability problems.

Sounds great to me, although I should warn you that I haven't actually
tried any of the code...

Just to make sure I understand things... could runProcess be implemented in
terms of runInteractive as below? Not that this would be wise--I imagine it
goes the other way around--but I want to be sure that I understand how I'd
want to modify things, for example if I wanted to interactively write to a
process, but have its output logged straight to a file.

runProcess c as menv (Just inh) (Just outh) (Just errh) =
  do (iinh, iouth, ierrh, ph) <- runInteractiveProcess c as menv
     instr <- hGetContents inh
     outstr <- hGetContents iouth
     errstr <- hGetContents ierrh
     forkIO $ do hPutStr outh outstr
                 hClose outh
     forkIO $ do hPutStr errh errstr
                 hClose errh
     forkIO $ do hPutStr iinh instr
                 hClose iinh
     return ph

this hGetContents followed by forkIO hPutStr hClose seems like it ought to
be relatively common.  Is there a simple command to just connect a read
handle to a write handle? That would be a useful function, I imagine... and
could be implemented much more efficiently if the contents weren't
converted to a lazy String in between.
-- 
David Roundy
http://www.abridgegame.org