I was initially building strictify on top of System.Process.runInteractiveCommand. However, I soon ran into a fairly significant issue with the interface. Even once the process I was calling had terminated, and I had explicitly closed all its buffers, a zombie sh process was left around from it. As I was spawning, sequentially, lots of processes, this soon consumed too many resources and errored out. As I understand it, the sh process is used for redirection (in fact, I ended up implementing a variant of the same thing on top of System.Posix.Process eventually) and needs to stick around for a while, so that issues with lazyIO don't prevent the handles provided by command from terminating before we've read everything we want to. However, at the same time, it seems like a terrible idea to have these buffers stick around *forever*. I dug into the haskell code, but didn't look at the foreign C calls it was based on. This behavior seems pretty clearly broken to me, but I'm not sure what the exact solution should be. Possibly providing an explicit API method to shut the process down? Possibly blocking on polling its buffers and terminating the sh instance once all three buffers are explicitly or implicitly closed? --Sterl.