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
On Mon, Jun 21, 2004 at 01:28:41PM +0100, Simon Marlow wrote:
On 20 June 2004 10:57, David Roundy wrote:
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.
Hmmmm. I see... I like the idea of having the handles closed immediately. Your implementation (unlike mine) also means that the haskell program will no longer be involved in the IO of the child process, which also seems like a very good thing, both efficiency-wise and stability-wise. -- David Roundy http://www.abridgegame.org
participants (2)
-
David Roundy -
Simon Marlow