From: Chet Ramey <chet.ramey@case.edu>
To: bug-readline@gnu.org, gdb@sourceware.org
Cc: chet@case.edu
Subject: Re: MinGW status for readline
Date: Tue, 11 Apr 2006 14:15:00 -0000 [thread overview]
Message-ID: <443BB2CA.20200@case.edu> (raw)
In-Reply-To: <20060407200149.GA28248@nevyn.them.org>
Daniel Jacobowitz wrote:
> 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:
Thanks, though that patch introduces a memory leak.
> 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.
One of the forces driving all of the contextual changes to readline
between versions 5.0 and 5.1 was the desire to avoid blocking reads
that weren't generated by the application. This is one of those
places. Even if readline thinks that this is the beginning of a
multi-character key sequence, it will still return control to the
application.
> 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.
Thanks, I fixed it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong. No day but today.
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/
next prev parent reply other threads:[~2006-04-11 13:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-07 20:11 Daniel Jacobowitz
2006-04-07 21:53 ` Bob Rossi
2006-04-08 6:31 ` Daniel Jacobowitz
2006-04-11 14:15 ` Chet Ramey [this message]
2006-04-11 14:33 ` Daniel Jacobowitz
2006-04-11 14:40 ` Chet Ramey
2006-04-11 15:12 ` Daniel Jacobowitz
2006-04-11 15:31 ` Chet Ramey
2006-04-12 1:01 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=443BB2CA.20200@case.edu \
--to=chet.ramey@case.edu \
--cc=bug-readline@gnu.org \
--cc=chet@case.edu \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox