
Thanks to all who responded about subprocesses. I've put together a proposal (attached) which I think does a reasonable job of providing both flexibility and ease of use for the common cases. Please comment! Rationale: - Terminology: a "command" is run by the shell, whereas a "process" is a raw filename and list of arguments. A command is turned into a process by means of the system-specific commandToProcess eg. on Unix this wraps it in "/bin/sh -c", but depending on the system it might do nothing except split the command into words. - The "command" versions are defined in terms of the "process" versions in the obvious way. - The "interactive" versions create pipes for stdin/stdout/stderr which can be used to communicate with the process, whereas the non-interactive versions will inherit the parent's stdin/stdout/stderr mappings. - We still need a low-level runProcess which takes Handles for the stdin/stdout/stderr of the sub-process, because this allows for redirection. In conjuction with a separate createPipe, runProcess can be used to build the popen-style interfaces (eg. runInteractiveProcess), but by supplying these as functions in their own right we can simplify the implementation by not creating and immediately destroying redundant Handles produced by createPipe. This should amount to a useful reduction in overhead for the interactive variants. - To send a string to the processes stdin without blocking, use: (in,out,err,pid) <- runInteractiveProcess "..." forkIO (hPutStr in str) - Waiting for sub-processes to terminate and retrieving their exit-codes is provided for; GHC's RTS will need some extra support so that waitForProcess doesn't block other threads. - If you want to change the working directory for the sub-process (provided by the old runProcess abstraction), use runCommand with "cd <dir>; ...". Cheers, Simon