patch applied (ghc): don't call Haskeline to read input when
stdin is not a terminal
judah.jacobson at gmail.com
Fri May 29 19:07:52 EDT 2009
On Fri, May 29, 2009 at 2:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 29/05/2009 08:59, Simon Marlow wrote:
>> Thu May 28 08:26:51 PDT 2009 Simon Marlow<marlowsd at gmail.com>
>> * 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?
More information about the Cvs-ghc