Hi Michael, Thank you for your answer. Conduits certainly are the best approach, but the output I am going to read is very short and the external program will only be called once or twice per execution so I think Lazy IO won't be problematic here. Best regards, Ernesto On Thu, Dec 11, 2014 at 10:18 AM, Michael Snoyman wrote:

You can use readProcess[1], but it has some downsides:

1. Can't specify all options to CreateProcess, e.g., working directory and environment variables. 2. Relies on lazy I/O

I use Data.Conduit.Process[2] for this kind of thing, which has a full tutorial[3]. However, it *does* involve non-base dependencies.

[1] http://www.stackage.org/haddock/2014-12-10-ghc78-exc/process-1.2.0.0/System-... [2] http://www.stackage.org/haddock/2014-12-10-ghc78-exc/conduit-extra-1.1.4.2/D... [3] https://www.fpcomplete.com/user/snoyberg/library-documentation/data-conduit-...

On Thu Dec 11 2014 at 11:11:12 AM Ernesto Rodriguez wrote:

...

Dear All,

I have a program which invokes an external program via exec. I wish to capture the standard output of the program without using external (temporary) files. Is it possible to create an in memory handle which I can tell exec to use as standard output of the invoked program. It would be great if it can be done without any extra dependencies.

Best,

-- Ernesto Rodriguez

Masters Student Computer Science Utrecht University

www.netowork.me github.com/netogallo

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo

On Thu Dec 11 2014 at 7:10:51 PM Donn Cave wrote:

On Thu, Dec 11, 2014 at 10:18 AM, Michael Snoyman wrote:

...

You can use readProcess[1], but it has some downsides:

1. Can't specify all options to CreateProcess, e.g., working directory and environment variables.

2. Relies on lazy I/O

I sure feel a pall of dread at the words "lazy I/O", but in this case, readProcess takes the curse off it by evaluating the output, am I right? Hence the repeated assurances in the documentation that it's strict.

I honestly don't know if the "curse" has been lifted in this case. It could be that readProcess is perfectly safe and (unlike hGetContents) doesn't have dangerous corner cases. I'm not certain. One other issue that I forgot to mention though is that you're required by the readProcess API to deal with the output from the process as textual data, which is often times not appropriate. And given how complicated the internals of readProcess are, it's highly unlikely someone would get that right on their first attempt to port the code to use ByteString. Michael