Date: Wed, 5 Nov 2003 00:28:53 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: deischen@freebsd.org Cc: freebsd-stable@freebsd.org Subject: Re: Serious (ha-ha) bug in 4.9-RELEASE Message-ID: <20031104232853.GA34632@falcon.midgard.homeip.net> In-Reply-To: <Pine.GSO.4.10.10311041137170.2711-100000@pcnet5.pcnet.com> References: <20031104162148.GA31794@falcon.midgard.homeip.net> <Pine.GSO.4.10.10311041137170.2711-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 04, 2003 at 11:46:39AM -0500, Daniel Eischen wrote: > On Tue, 4 Nov 2003, Erik Trulsson wrote: > > > On Tue, Nov 04, 2003 at 07:49:36AM -0800, Michael Sierchio wrote: > > > Brian T. Schellenberger wrote: > > > > > > > > > >OTOH, the fact that nobody seems to have noticed until after 4.9 was > > > >released is a pretty strong argument that not very many people > > > >care--unless of course :-) > > > > > > Arrrrghhhh! It was a stupid fscking idea to make > > > arbitrary changes to something that hadn't really changed > > > in a decade (or more). > > > > I don't think the changes were exactly arbitrary. > > >From the comments in termcap.src I would say that the new version seems > > to be based (quite closely) on the termcap desctriptions supplied by > > the XFree86 people. From browsing their CVS repository it seems they > > dropped the "bs" capability from their xterm entry some 7 years ago. > > It has also been in 4-STABLE for about 6 months (and in -CURRENT for > > about 7 months before that), so it is not exactly as if it was a new > > and untested change that made it into 4.9-RELEASE. > > > > Many people wanted support for various new features in xterm (like > > support for color in a standard xterm.) > > To get those, the termcap entry needed to be updated. > > The easiest (and least bug-prone) way of doing that seems to be to > > import the termcap entries provided by XFree86 (who, after all, should > > know what xterm looks like.) > > > > > > > > And I don't track -STABLE on all machines, so this change > > > didn't appear in RELENG_4_8. > > > > The changes were made after 4.8-RELEASE, so they wouldn't have appeared > > in RELENG_4_8. > > > > > > > > Especially since it affects such a *critical* application ;-) > > > > Very critical indeed... And with such a huge userbase that it took six > > months before anybody noticed this problem. :-) > > No, we noticed it here at work where we use Sun Solaris > boxes as our development systems. I didn't know what the > problem was until now. It is very very annoying to have > man, more, less, etc, screw up your display when using > them while remotely logged in to our FreeBSD boxes. The > symptoms are that everything gets highlighted and underlined > and it stays that way forcing you to close the xterm and > open another. If we set TERM to xterm-r6 or xterm-r5, then > everything seems to work OK. I don't think this is quite the same problem. The problem discussed earlier was that /usr/games/hack required that the terminal supported a long-obsolete capability which is no longer provided with the current termcap entry for xterm. I have run into similar problems as your before, but not involving FreeBSD, but rather Solaris/Linux. This is what can happen when the termcap description does not describe the terminal used. The termcap entry for xterm in most systems describe the xterm that is included in the system. Not all xterms are equivalent. What happens in this case is that the program running on the remote (FreeBSD/Linux) box consults the termcap entry on that machine. This correctly describes the xterm capabilities for an xterm running on the remote machine. The xterm running on the local (Solaris) machine, which is actually handling the display, is not correctly described by that entry but requires a different termcap description. The error here is assuming that the 'xterm' termcap entry correctly desribes all programs called xterm. This is not always true. The solution, as you found, is to set TERM to a terminal type that correctly describes the terminal type actually used. In this case xterm-r6 or xterm-r5. Personally I tend to solve this in another way, which is by running screen(1) at the local machine and setting TERM=vt102. This way I don't have to worry about which termcap entry should be used. screen(1) uses the local (presumably correct) entry, while the remote application only needs to worry about what control sequences screen(1) handles (which is usually described quite well by "vt102".) > > I hate how xterm defaults to color-capable. If it were > only up to me, it wouldn't. I can agree with that. I really don't want applications to start displaying colored text in terminal windows unless I explicitly ask them to. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031104232853.GA34632>