This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
MinGW status for readline
- From: Daniel Jacobowitz <drow at false dot org>
- To: bug-readline at gnu dot org
- Cc: gdb at sourceware dot org
- Date: Fri, 7 Apr 2006 16:01:49 -0400
- Subject: MinGW status for readline
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