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) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe