trying to understand runProcess handles

hi there, I am running some unix command. I just realized there is runInteractiveProcess in System.Process, so my problem is solved in practice: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ showPlot :: String -> IO (Handle, Handle, Handle, ProcessHandle) showPlot file = runInteractiveProcess executable arguments wd env where executable = "/usr/bin/gnuplot" arguments = ["-geometry", "-19+3", file, "-"] wd = Nothing env = Nothing ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ But first I tried to create the handles myself with createPipe from System.Posix.IO, and I failed for a reasons that I have no clue how to learn to understand. This is what the code looked like: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ showPlot :: String -> IO (ProcessHandle, Handle, Handle, Handle) showPlot file = do (stdinR, stdinW) <- createPipeHandles (stdoutR, stdoutW) <- createPipeHandles (stderrR, stderrW) <- createPipeHandles h <- runProcess executable arguments wd env (Just stdinR) (Just stdoutW) (Just stderr W) return (h, stdinW, stdoutR, stderrR) where executable = "/usr/bin/gnuplot" arguments = ["-geometry", "-19+3", file, "-"] wd = Nothing env = Nothing createPipeHandles :: IO (Handle, Handle) createPipeHandles = do (fR, fW) <- createPipe hR <- fdToHandle fR hW <- fdToHandle fW return (hR, hW) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The problem is that gnuplot terminates right away after it tries to read from stdin (I can see the shadow of a window appear and vanish immediately). I tried setFdOption, with no effect. Is this because the handles passed to runProcess are closed in the parent process, and therefore the pipe is teared down and useless? I don't think so: If I run 'find /' instead of gnuplot, the process happily starts and I can hGetLine from stdout. If you have any clue I'd love to learn. Anyway, as I said, it's really better to simply use runInteractiveProcess in this simple case. thanks, Matthias

On Thu, 2 Mar 2006, Matthias Fischmann wrote: ...
The problem is that gnuplot terminates right away after it tries to read from stdin (I can see the shadow of a window appear and vanish immediately). I tried setFdOption, with no effect. Is this because the handles passed to runProcess are closed in the parent process, and therefore the pipe is teared down and useless?
I don't think so: If I run 'find /' instead of gnuplot, the process happily starts and I can hGetLine from stdout.
That doesn't necessarily disprove your hypothesis, since "find" doesn't read input. You might try "tr" instead, for example. I don't see anything about what you were doing that would be obviously different from runProcessInteractive, but as long as you're making a pipe for error output, you may as well read it and see if gnuplot has left any clue to its problem there. Donn Cave, donn@drizzle.com

On Fri, Mar 03, 2006 at 09:05:49AM -0800, Donn Cave wrote:
To: haskell-cafe@haskell.org From: Donn Cave
Date: Fri, 3 Mar 2006 09:05:49 -0800 (PST) Subject: Re: [Haskell-cafe] trying to understand runProcess handles On Thu, 2 Mar 2006, Matthias Fischmann wrote: ...
The problem is that gnuplot terminates right away after it tries to read from stdin (I can see the shadow of a window appear and vanish immediately). I tried setFdOption, with no effect. Is this because the handles passed to runProcess are closed in the parent process, and therefore the pipe is teared down and useless?
I don't think so: If I run 'find /' instead of gnuplot, the process happily starts and I can hGetLine from stdout.
That doesn't necessarily disprove your hypothesis, since "find" doesn't read input. You might try "tr" instead, for example. I don't see anything about what you were doing that would be obviously different from runProcessInteractive, but as long as you're making a pipe for error output, you may as well read it and see if gnuplot has left any clue to its problem there.
that doesn't work -- all the handles are closed at least after the process has died. hard to tell whether the process dying caused the handles to close or whether the handles were closed already by then. m.

On Fri, 3 Mar 2006, Matthias Fischmann wrote:
... but as long as you're making a pipe for error output, you may as well read it and see if gnuplot has left any clue to its problem there.
that doesn't work -- all the handles are closed at least after the process has died. hard to tell whether the process dying caused the handles to close or whether the handles were closed already by then.
Process exit closes the process' end of the pipes, but can't do anything to the other end. When it closes the write end, a read on the other end returns with end of file. The same pipe file descriptor may be inherited by multiple processes, any one of which may hold it open - only the last close matters. That's why functions like runProcess normally close the opposite ends of the pipe, in the parent & child forks, so that the parent doesn't hold the child's open or vice versa. Donn Cave, donn@drizzle.com
participants (2)
-
Donn Cave
-
Matthias Fischmann