On Tue, 2009-10-27 at 17:00 +0100, Daniel Fischer wrote:
Look at the sources:
hGetLine :: Handle -> IO ByteString hGetLine h = wantReadableHandle "Data.ByteString.hGetLine" h $ \ handle_ -> do case haBufferMode handle_ of NoBuffering -> error "no buffering" _other -> hGetLineBuffered handle_
where ...
So, in ghci, stdin isn't buffered and ByteString can't cope with that. Why exactly, I don't know.
By comparison if we look at System.IO.hGetLine we see: hGetLine :: Handle -> IO String hGetLine h = do m <- wantReadableHandle "hGetLine" h $ \ handle_ -> do case haBufferMode handle_ of NoBuffering -> return Nothing LineBuffering -> do l <- hGetLineBuffered handle_ return (Just l) BlockBuffering _ -> do l <- hGetLineBuffered handle_ return (Just l) case m of Nothing -> hGetLineUnBuffered h Just l -> return l So there is something special about an unbuffered hGetLine. I can't remember exactly but when we implemented hGetLine for ByteString I guess we didn't understand / couldn't be bothered with the weird unbuffered case. The System.IO code in ghc-6.10 also notes: -- ToDo: the unbuffered case is wrong: it doesn't lock the handle for -- the duration. In ghc-6.12 I think the unbuffered mode for input was simply abolished so there is no longer a hGetLineUnBuffered case. Duncan