X-Spam-Check-By: sourceware.org Message-ID: <441F673C.8000206@fastmail.fm> Date: Mon, 20 Mar 2006 21:38:52 -0500 From: Charles Wilson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: rxvt and line-drawing characters References: <4406222B DOT F2EB92DA AT dessent DOT net> <440669A1 DOT 65F0752C AT dessent DOT net> <4406767C DOT 5030109 AT cwilson DOT fastmail DOT fm> In-Reply-To: <4406767C.5030109@cwilson.fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Charles Wilson wrote: > Strangely, if I set TERM=rxvt-cygwin-native , use luconP as my font , it > does NOT matter whether my CYGWIN variable has codepage:oem, > codepage:ansi, or neither. The following behaviors are the same: > > ascii.exe prints the line draw characters > pstree -G prints garbage > > It *could be* due to the fact that pstree uses ncurses, and ascii does > not. Checking... > > Hmmm. /usr/lib/ncurses/test/ncurses.exe (part of the ncurses-demo > package) turns the screen black-on-black when I try to check the > line-draw characters. So I can't even tell if ACS chars with ncurses is > broken -- first I gotta figure out why the colors are getting scrogged > by the test program! Somebody, like the ncurses maintainer, should fix > that. > > Oh. That'd be me, then. Ooops. I'll try to look into it soon, but PTC. Okay, so I've looked into this. (1) the ncurses "problem" is not a problem. The ncurses.exe test program leaves the decision as to whether to use colorfgbg() defaults up to the user (-a fg,bg to explicitly specify defaults, -d to inherit defaults from rxvt, or '' to use the DEFAULT defaults. Which is, apparently, black on black -- at least when run in an rxvt shell.) So, running ncurses.exe with -d, (or, for that matter, the hideous -a 1,4 == red-on-blue, unless you've redefined rxvt's colors) works fine. With rxvt -fn 'Lucida ConsoleP-16' -tn rxvt-cygwin-native -e /bin/bash I get nice line draw characters from the ncurses.exe test program. With rxvt -fn 'Lucida Console-16' -tn rxvt-cygwin-native -e /bin/bash I get "european" characters where the line drawing ones used to be. Just as expected. Also, codepage:oem|ansi has no effect -- it only applies when using the windows console, not when using rxvt. (2) So why does pstree misbehave? Because it's hardcoded to use VT-100 control characters for line drawing. But that's EXACTLY where rxvt differs from VT-100 (and where rxvt-cygwin differs from rxvt, and where rxvt-cygwin-native differs from them all). pstree SHOULD be using tgetent() calls to dynamically obtain the appropriate line-drawing character codes and escape sequences from ncurses/terminfo. But it doesn't. (There's also a similar bug in that it doesn't always calculate accurately the width of strings in which these line-draw chars are embedded...but that's a whole 'nother thing.) Basically, pstree -G should be rewritten; it's just not going to work on cygwin's rxvt (native or X) very well. "It's surely evil code" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265552 Basically, you're stuck with 'pstree -A'. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/