On 30/05/2009 00:07, Judah Jacobson wrote:
On Fri, May 29, 2009 at 2:34 AM, Simon Marlow<[email protected]>  wrote:
On 29/05/2009 08:59, Simon Marlow wrote:
Thu May 28 08:26:51 PDT 2009  Simon Marlow<[email protected]>
   * don't call Haskeline to read input when stdin is not a terminal
   Ignore-this: 3810fe8dff7e0a8b4ec013f47e33cc4c

     M ./ghc/InteractiveUI.hs -9 +10
This fixes the GHCi failures of the form "hLookAhead: bad file descriptor"
in HEAD.  The underlying problem is that these tests eventually close stdin,
by virtue of calling hGetContents (or interact, or readFile) and reaching
EOF on stdin.  Since we have two stdins in GHCi, only the program's stdin
Handle is closed, GHCi's stdin Handle is left open, but the underlying file
descriptor has been closed.  So the next attempt to read from stdin in GHCi,
which happens to be in Haskeline, gets a bad file descriptor error.

It so happens that if we read stdin directly rather than using Haskeline,
then GHCi has a special shim to Handle this case (InteractiveUI.fileLoop)
and behave as for EOF on stdin.  So the workaround is to use ordinary file
reading when stdin is not a TTY, which is what we used to do before
Haskeline.  I think this is the right thing to do anyway.

Ian: we ought to merge this into 6.10.4, I think.


Haskeline does already check whether stdin is a tty, and if not it
just uses getLine rather than the fancy terminal stuff.  So adding the
above logic would be redundant, except that Haskeline doesn't handle
the InvalidArgument exception.

Maybe Haskeline should be changed to handle that situation?  Then we
wouldn't need the extra code in ghci.  Or is this type of exception so
esoteric that it wouldn't occur in any other applications?

Ah, I didn't know that. I don't think you should add extra code in Haskeline to handle this, it's really a GHCi oddity. So I think I could revert the change I made and instead just catch the InvalidArgument exception from Haskeline, but that wouldn't result in any less code. In fact we'd be catching the exception in two places. So I think I'll just leave things as they are for now; the problem is documented in the comments in InteractiveUI.

Cheers,
        Simon


_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to