> > We're groping around in the dark here
>
> Sorry, yes we are. It is a bit cheeky of me to always punt and say
> "I'll bet it is a GHC problem" when I haven't even seen the bug myself
> on a machine whose configuration I know. Sorry about that.
No problem :)
> In fact, it turns out that y
> On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
> > Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
> > > - If instead the child's child (echo.c) closes stdin
> immediately after
> > > being executed, some data is lost.
> >
> > Where's the use in closing stdin when you're passing arguments
> > Yes, it's a NOP (just to be sure). The difference is in child.hs:
> >
> > callIO (\ps -> "Kommando fehlgeschlagen mit " ++ show ps
> > ++ ":\n" ++ kommando prog par)
> >(executeFile' prog True par Nothing)
> > -- instead, to avoid bug:
> > -- (hClose stdin >> exec
Am 18. Mar 2002 um 13:51 MET schrieb Simon Marlow:
> unevaluated until the child process needs to construct its argument list
> to pass to executeFile. Hence the child process pokes on the lazy
> stream, and when the parent process subsequently demands data from the
> lazy stream, there is a buff
On Mon, 2002-03-18 at 13:51, Simon Marlow wrote:
> Ok, here's my explanation. [...]
I see...
Yet, it doesn't explain why the problem disappears if you close stdin
before calling executeFile, like this:
callIO :: (ProcessStatus -> String)
-> IO ()
-> IO ()
callIO fm io = do
ma
> On Mon, 2002-03-18 at 13:51, Simon Marlow wrote:
> > Ok, here's my explanation. [...]
>
> I see...
>
> Yet, it doesn't explain why the problem disappears if you close stdin
> before calling executeFile, like this:
>
> callIO :: (ProcessStatus -> String)
>-> IO ()
>-> IO ()
>
