trying to understand runProcess handles

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

trying to understand runProcess handles

Matthias Fischmann


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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand runProcess handles

Donn Cave-2
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, [hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand runProcess handles

Matthias Fischmann
On Fri, Mar 03, 2006 at 09:05:49AM -0800, Donn Cave wrote:

> To: [hidden email]
> From: Donn Cave <[hidden email]>
> 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.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand runProcess handles

Donn Cave-2
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, [hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe