| Anything involving sharing file descriptors between processes becomes
| similarly broken if the GHC runtime starts using a file descriptor as a
| Handle. You're not the only one to be surprised by this behaviour, but
| unfortunately it's not trivial to work around.
|
| Simon Marlow was going to
On Sun, Jul 29, 2007 at 10:34:10AM -0700, Bryan O'Sullivan wrote:
>
> Simon Marlow was going to look into this problem a few months ago, but I
> don't know if he's had a chance to.
It's fixed in the HEAD:
http://hackage.haskell.org/trac/ghc/ticket/724
Thanks
Ian
__
On Sun, Jul 29, 2007 at 10:34:10AM -0700, Bryan O'Sullivan wrote:
> GHC's file handles are backed by non-blocking file descriptors. The
> child process run by executeFile inherits the stdin, stdout and stderr
> file descriptors of your Haskell process, so they're unexpectedly (from
> its persp
Krzysztof Kościuszkiewicz wrote:
This works for files, but "randomly" fails when stdin is connected to
a pipe (pstops complains that it can't seek input).
GHC's file handles are backed by non-blocking file descriptors. The
child process run by executeFile inherits the stdin, stdout and stder
Fellow Haskellers,
I wrote a small script that intercepts arguments and exec's the pstops
program. The intention was to center and scale pages in a document
before processing it by psnup.
So far so good, I've ended up with something like:
> runPstops :: [Flag] -> IO ()
> runPstops flags =
> do
