System.Process

[Simon Marlow]

On 20 June 2004 10:57, David Roundy wrote:

>> 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.

Oops, that was left over from a previous version.  Now fixed.

>> 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. 

Yes, I had in mind providing 'system' and 'rawSystem' replacements too.

>> 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

Hmm, looks like that might work, yes.  It's not quite the same, though:
in your version, the inh Handle ends up semi-closed, whereas in the
current runProcess implementation it is closed immediately.  In your
implementation, the outh and errh handles are closed when all the output
has been written to them; in my implementaiton they are closed
immediately.  (I just noticed that my Windows implementation differs
from the Unix implementation in this respect).

Closing these handles immediately seems more deterministic, but I'm not
sure which is the most "useful" behaviour.

Cheers,
	Simon