[Haskell-cafe] When is waitForProcess not necessary?

[Donald Bruce Stewart]

bayer:
> If one is calling runInteractiveCommand for a "sure-thing" returning a small
> amount of output (say, "ls" for a modest directory"), is it necessary to call
> waitForProcess?
> 
> My waitForProcess calls came under scrutiny when I tried to GHC profile a
> threaded process, which isn't possible. It turns out that my programs run
> faster if they don't call waitForProcess, and it sure seems empirically
> that they never fail to run correctly. It would seem to me that in a lazy
> language, later code wouldn't presume it was looking at an entire string
> until the actual EOF came through, completing the string.
> 
> So at the end of a program, with nothing else to do but wait, why not wait
> "implicitly" rather than via an explicit call to waitForProcess? What am I
> missing?
> 
> (I've searched this forum; an interesting example is runCommand in
> 
> 
>     http://happs.org/HAppS/src/HAppS/Util/Common.hs
> 
> but I'm asking why this isn't overkill in my scenario. I'm actually calling
> Markdown.pl on tiny files (source code of lengths a human would read), and
> it is certainly sluggish enough to be a fair test.)
> 
> _______________________________________________

You might be interested in :

    http://www.cse.unsw.edu.au/~dons/code/newpopen/

In particular,
        
    readProcess :: FilePath                     -- ^ command to run
                -> [String]                     -- ^ any arguments
                -> String                       -- ^ standard input
                -> IO (Either ExitCode String)  -- ^ either the stdout, or an exitcode
            
Strict String IO for processes, without the zombies.

-- Don Stewart (Authorised by the "People for System.IO.Strict" party)