On Tue, 19 Aug 2003 dshaw@jabberwocky.com wrote:

: State-Changed-From-To: open->feedback

: The buffering oddity you are seeing with "tee" is because
: tee doesn't finish pocessing until the input file is closed.

Uh, no, wrong.  tee will process anything it gets, at least on NetBSD; it
works "properly" on explicitly line-buffered output.  But now that you
mention it and I think about the stdout buffering aspect -- if I hit "Q",
the hidden key list finally shows up.

(Remember that my problem comes from PGP/GPG frontends, which will usually
redirect stdout through a filtered pipe for screen formatting purposes.
Since that means stdout is not a tty in gpg, the OS chooses a block-buffered
rather than line-buffered strategy for stdout.)

So, it appears that gpg is depending on the OS to choose the proper
buffering strategy for stdout, which is wrong for an inherently interactive
operation.  gpg should either (1) do a setlinebuf() or setvbuf() on stdout
to guarantee line buffering for the interactive output of --search-keys, or
(2) do a fflush(stdout) after printing the whole key list.

I'm happy with either solution but prefer (2), and the change is trivial.
It is implemented here against GnuPG 1.2.2:

--- g10/keyserver.c.orig	Mon Aug 18 22:45:39 2003
+++ g10/keyserver.c	Mon Aug 18 22:47:42 2003
@@ -1078,6 +1078,8 @@

       if(i%10==0 || rl==0)
 	{
+	  /* flush printed keylist before prompt */
+	  fflush(stdout);
 	  answer=cpr_get_no_help("keysearch.prompt",
 				 _("Enter number(s), N)ext, or Q)uit > "));
 	  /* control-d */

-- 
-- Todd Vierling <tv@pobox.com>