From 6e67363d0c40886321e59b191a2520f4d8c83666 Mon Sep 17 00:00:00 2001
From: simonmar <unknown>
Date: Wed, 25 Feb 2004 10:34:44 +0000
Subject: [PATCH] [project @ 2004-02-25 10:34:44 by simonmar] Add an entry to
 the FAQ about buffering of stdout

---
 ghc/docs/users_guide/faq.sgml |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/ghc/docs/users_guide/faq.sgml b/ghc/docs/users_guide/faq.sgml
index f9b27ab..21c2434 100644
--- a/ghc/docs/users_guide/faq.sgml
+++ b/ghc/docs/users_guide/faq.sgml
@@ -340,6 +340,38 @@ details.</para>
         lose Ctrl-D.  C'est la vie.</para>
       </listitem>
     </varlistentry>
+
+    <varlistentry>
+      <term>If I print out a string using <literal>putStr</literal>,
+      and then attempt to read some input using
+      <literal>hGetLine</literal>, I don't see the output from the
+      <literal>putStr</literal>.</term>
+
+      <listitem>
+	<para>The <literal>stdout</literal> handle is line-buffered by
+	default, which means that output sent to the handle is only
+	flushed when a newline (<literal>/n</literal>) is output, the
+	buffer is full, or <literal>hFlush</literal> is called on the
+	Handle.  The right way to make the text appear without sending
+	a newline is to use <literal>hFlush</literal>:</para>
+
+<programlisting>
+  import System.IO
+  main = do
+    putStr "how are you today? "
+    hFlush stdout
+    input <- hGetLine
+    ...</programlisting>
+
+	<para>You'll probably find that the behaviour differs when
+	using GHCi: the <literal>hFlush</literal> isn't necessary to
+	make the text appear.  This is because in GHCi we turn off the
+	buffering on <literal>stdout</literal>, because this is
+	normally what you want in an interpreter: output appears as it
+	is generated.</para>
+      </listitem>
+    </varlistentry>
+
   </variablelist>
 </chapter>
 
-- 
1.7.10.4