This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 173976 - New xterm termcap entry often makes cursor disappear
New xterm termcap entry often makes cursor disappear
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: termcap (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-23 06:15 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-23 12:09:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description JW 2005-11-23 06:15:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217

Description of problem:
There is some sort of glitch with the "xterm" termcap definition that makes the cursor disappear occasionally.  It can be made to reappear by using the left or right arrow keys (in vi).  When it disappears it appears as though the character at the cursor position has vanished, but that is only because the block cursor has turned black (instead of white) and thereby obscures the character.


Version-Release number of selected component (if applicable):
termcap-5.4-7fc4

How reproducible:
Sometimes

Steps to Reproduce:
1.v/bin/vi /etc/termcap
2.    /xxxxxxxx<enter>
3.

  

Actual Results:  cursor disappears (remains black)



Expected Results:  cursor should always be white


Additional info:

Have reverted to termcap-5.4-4 which solves the problem.

The trouble is, why does /etc/termcap have to change every few weeks? Surely once xterm ctlseq's are defined that should be the end of story for a few years at least.

That is the fundamental problem with configurability - give people something to fiddle with and what do they go and do?  Yes, fiddle with it. And that is why there are so many variants of xterm definitions.
Comment 1 JW 2005-11-23 06:25:50 EST
Please change:
   How reproducible: Always
Comment 2 Petr Raszyk 2005-11-23 12:09:00 EST
'vi' ('vim') and dynamically linked libraries (libtermcap.so.2) (in FEDORA CORE
4) do not read /etc/termcap.
'vi' reads terminfo-database.
Comment 3 JW 2005-11-23 18:25:59 EST
(In reply to comment #2)
> 'vi' ('vim') and dynamically linked libraries (libtermcap.so.2) (in FEDORA CORE
> 4) do not read /etc/termcap.
> 'vi' reads terminfo-database.

If that is true, then come is it that by replacing /etc/termcap with an earlier
version, my problem went away.

Also, if that is true then how come when I used strace on /bin/vi it showed it
reading /etc/termcap.

Sorry, but you are mistaken.

Also, libtermcap is used to access /etc/termcap (do strings on it if you like).
Terminfo is accessed via libncurses.

Besides, you cannot draw conclusions from what ldd shows - a program might be
statically linked.
Comment 4 Petr Raszyk 2005-11-24 13:56:50 EST
A mail from jw203198@hotmail.com

How on earth can you close a bug based on totally wrong
conlusion?

Do you know what you are doing?

I mean, to say that because /bin/vi dynamically links
with libtermcap therefore it is using terminfo is
the weirdest nonsense I have heard in a long time.

Are you sure you understand that libtermcap != terminfo?

Please, get your facts straight!

Vi does *not* link with libncurses which is where terminfo
is handled.

Do "strings /usr/lib/libtermcap | grep termcap" to
satisfy yourself about /etc/termcap.

Perhaps you should take the time to actually reproduce the steps that
I took to trouble to itemise before mouthing off with ludicrous statements.

Really!

Regards
John Witford

Comment 5 Petr Raszyk 2005-11-24 13:59:09 EST
No duplicity.
See #174036
See Bugzilla Bug 174036

Note You need to log in before you can comment on or make changes to this bug.