Subject: Re: port-amd64/34282: console color is broken on amd64 when using pkgsrc/misc/screen on amd64
To: None <port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: George Georgalis <george@galis.org>
List: netbsd-bugs
Date: 10/04/2006 13:25:02
The following reply was made to PR port-amd64/34282; it has been noted by GNATS.
From: "George Georgalis" <george@galis.org>
To: Thomas Dickey <dickey@radix.net>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-amd64/34282: console color is broken on amd64 when using pkgsrc/misc/screen on amd64
Date: Wed, 4 Oct 2006 09:23:55 -0400
On Wed, Oct 04, 2006 at 08:43:34AM -0400, Thomas Dickey wrote:
>On Wed, Oct 04, 2006 at 11:56:08AM +0000, George Georgalis wrote:
>> On Wed, Oct 04, 2006 at 06:04:10AM -0400, Thomas Dickey wrote:
>> >On Tue, Oct 03, 2006 at 08:15:32PM +0000, George Georgalis wrote:
>> >> I've localized the problem to the .Xdefaults entry:
>> >
>> >The report was for "OOPS", which would come from an application running
>> >within xterm (or whatever terminal). There's no mechanism that would
>> >make xterm send "OOPS" by itself that I can think of.
>>
>> My report was for ANY use of color control sequences (eg colorls,
>> vim, etc) within screen generate a literal "OOPS" instead, when
>> connecting to amd64. Removing "xterm*colorRVMode: true" from
>> Xdefaults FIXES the problem. at the expense of disabling a
>> feature I want.
>
>But a termcap application can't tell if xterm has the resource set.
>It is the termcap application that sends the "OOPS".
>
>The likely explanation for the "OOPS" is mishandling of a truncated termcap,
>e.g., if some color information is missing. NetBSD's termcap implementation
>substitutes an address for the missing information. Recent discussion of this
>problem hints that the size of the address data is a factor, e.g., there could
>be a buffer overflow due to the added bits (not a bug in xterm ;-).
>
>However, none of the comments made on the mailing lists have identified the
>problem other than the oblique comment that it has been fixed in some version.
>(Since no analysis has been presented, it is unlikely that it is fixed).
That make some sense to me, though I don't really understand.
Christos suggested trying current sources, but I've had
(unrelated) problems trying that.
Other than that I don't know what else to try or any additional
info I can provide. Is there any specific thing I can do that may
be useful?
// George
--
George Georgalis, systems architect, administrator <IXOYE><