From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2521 invoked by alias); 9 Dec 2002 22:33:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2507 invoked from network); 9 Dec 2002 22:33:30 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 9 Dec 2002 22:33:30 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id gB9MXPb32014; Mon, 9 Dec 2002 16:33:25 -0600 Date: Mon, 09 Dec 2002 14:38:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200212092233.gB9MXPb32014@duracef.shout.net> To: carlton@math.stanford.edu Subject: Re: [PATCH] Merge of readline 4.3 to mainline Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com X-SW-Source: 2002-12/txt/msg00301.txt.bz2 > Do you have anything strange in your .inputrc? I skimmed through the > readline docs and didn't see any variables that would produce this > behavior, but I thought I'd ask just in case... I don't have a .inputrc file at all. And I'm sure I don't have a different one than I had last week. If other people have nice-looking gdb.log files, and I have a funny-looking gdb.log file, that implies that readline is conditionally acting on something that I have that other people don't. So my theory is that we just find that thing and hard-wire it to "always print the simple way". I guess I'm in the best position to find the magic logic because I'm the guy with the anomolous output. I'm tracing through readline/display.c:rl_redisplay(), and I see that it's got different code for HANDLE_MULTIBYTE. This code is definitely turned on for my system. One of the big changes in Red Hat Linux 8 is unicode support in the console. There are two ways to check this: look in the build log for the place that readline gets configured. Mine says: checking for tgetent in -ltermcap... yes checking which library has the termcap functions... using libtermcap checking for wctype.h... yes checking for wchar.h... yes checking for langinfo.h... yes checking for mbsrtowcs... yes checking for wcwidth... yes checking for mbstate_t... yes If all of wctype.h, wchar.h, and mbsrtowcs are turned on, then HAVE_MULTIBYTE is defined, and rl_redisplay has different logic. You can also start gdb, break on rl_redisplay, and check for a local variables named "wc" and "wc_bytes". If they exist, then HAVE_MULTIBYTE was configured in. The old readline 4.1 does not have this HAVE_MULTIBYTE code at all. I suspect that's why it worked on my system. More source diving to follow ... at the moment I am just suspicious of HAVE_MULTIBYTE, it could be something else. Michael C