MinGW status for readline

[Daniel Jacobowitz <drow at false dot org>]

Hi Chet,

I just tried to use GDB with readline 5.1, on MinGW32.  I have four
items to report.  #1 and #4 have readline patches, #2 I'll fix in GDB,
#3 is a readline bug that I do not know how to fix - I'd appreciate
advice on that one!

1.  Readline 5.1 currently fails to build for MinGW, in tilde.c.  The
problem is:

      dirname = glue_prefix_and_suffix (user_entry->pw_dir, filename, user_len);

I've just moved the else branch inside the #if defined (HAVE_GETPWENT),
from just below.  With that change, readline builds.  Here's the patch:

2006-04-07  Daniel Jacobowitz  <dan@codesourcery.com>

	* tilde.c (tilde_expand_word): Don't use pw_dir if !HAVE_GETPWENT.

--- /space/symbian/readline/readline-5.1/tilde.c	2005-05-07 14:49:51.000000000 -0400
+++ ./tilde.c	2006-04-07 14:16:10.000000000 -0400
@@ -410,12 +410,12 @@ tilde_expand_word (filename)
       if (dirname == 0)
 	dirname = savestring (filename);
     }
+#if defined (HAVE_GETPWENT)
   else
     {
       free (username);
       dirname = glue_prefix_and_suffix (user_entry->pw_dir, filename, user_len);
     }
-#if defined (HAVE_GETPWENT)
   endpwent ();
 #endif
   return (dirname);


2.  The changes in the handling of multi-key sequences cause control to
return to GDB between \0340 and the following 'H' (two-character
sequence indicating an arrow key).  This used to happen entirely in
readline.  I don't think this is a bug in readline, though it did
surprise me.  It also broke GDB's select implementation for MinGW32,
but that's my problem, not yours.

3.  RL_STATE_MULTIKEY also broke macros which push multi-key sequences
into the input stream.  For instance, put this in .inputrc:
  Control-y: "\e[D"

Then try to use that.  It works in bash, which does not use callback
mode; it fails in GDB, which does.  All the other readline-using apps
I checked on my system don't use callbacks, so I couldn't be sure it
wasn't GDB's fault, but I don't think it is.

What happens in GDB is that rl_callback_read_char has special handling
for various states, including RL_STATE_MULTIKEY.  But if there's a
macro in progress, it just loops at the bottom checking
RL_STATE_MACROINPUT and calling readline_internal_char.  This doesn't
use the keymap saved in _rl_kscxt.  So the escape character is not
properly handled, and I get a beep followed by a literal [D.  I think
this is readline's fault.

4.  There's some use of uninitialized variables when checking for
pending input on mingw32, because we exercise the no-select code path,
so here's a patch to fix that.  I was hoping that this would fix #2,
but I'm going to have to fix that in GDB instead.  The patch is still
right, though, so please apply.  (The uninitialized variable was
chars_available.)

2006-04-07  Daniel Jacobowitz  <dan@codesourcery.com>

	* input.c (rl_gather_tyi): Use _kbhit for Windows consoles.
	(_rl_input_available): Likewise.

--- readline-5.1.orig/input.c	2005-07-04 22:30:24.000000000 -0400
+++ readline-5.1/input.c	2006-04-07 15:04:57.000000000 -0400
@@ -220,6 +220,16 @@ rl_gather_tyi ()
     }
 #endif /* O_NDELAY */
 
+#if defined (__MINGW32__)
+  /* We use getch to read console input, so use the same
+     mechanism to check for more.  Otherwise, we don't know.  */
+  if (isatty (fileno (rl_instream)))
+    chars_avail = _kbhit ();
+  else
+    chars_avail = 0;
+  result = 0;
+#endif
+
   /* If there's nothing available, don't waste time trying to read
      something. */
   if (chars_avail <= 0)
@@ -305,6 +315,13 @@ _rl_input_available ()
 
 #endif
 
+#if defined (__MINGW32__)
+  /* We use getch to read console input, so use the same
+     mechanism to check for more.  Otherwise, we don't know.  */
+  if (isatty (fileno (rl_instream)))
+    return _kbhit ();
+#endif
+
   return 0;
 }
 


-- 
Daniel Jacobowitz
CodeSourcery