Bug 174036 - New xterm termcap entry often makes cursor disappear
New xterm termcap entry often makes cursor disappear
Status: CLOSED NOTABUG
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 18:34 EST by JW
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

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


Attachments (Terms of Use)
libtermcap.so.2.0.8 (incl. net-autotrace) (68.21 KB, application/octet-stream)
2005-11-24 12:06 EST, Petr Raszyk
no flags Details
a server (presents app-logs/traces via network) (52.62 KB, application/octet-stream)
2005-11-24 12:10 EST, Petr Raszyk
no flags Details

  None (edit)
Description JW 2005-11-23 18:34:21 EST
+++ This bug was initially created as a clone of Bug #173976 +++

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.

-- Additional comment from jw203198@hotmail.com on 2005-11-23 06:25 EST --
Please change:
   How reproducible: Always


-- Additional comment from praszyk@redhat.com on 2005-11-23 12:09 EST --
'vi' ('vim') and dynamically linked libraries (libtermcap.so.2) (in FEDORA CORE
4) do not read /etc/termcap.
'vi' reads terminfo-database.

-- Additional comment from jw203198@hotmail.com on 2005-11-23 18:25 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 1 Thomas E. Dickey 2005-11-23 19:57:59 EST
The termcap isn't going to affect the cursor color, only whether
it's visible or not.  What are the differences between the old and
new entries?
Comment 2 Mike A. Harris 2005-11-24 10:19:10 EST
Reassigning to proper component owner...
Comment 3 Petr Raszyk 2005-11-24 11:43:38 EST
A mail from w203198@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 4 Petr Raszyk 2005-11-24 11:50:44 EST
First test:
Delete /etc/termcap (mv /etc/termcap /etc/termcap2). 
Launch an xterm (but not as root). 
Launch at the command prompt: export TERM=xterm
Launch at the command prompt: vi aaa.txt
It works ! 'vi' does not read termcap !!!
(/etc/termcap does not exist. 'vi' cannot read
a non-existing file).

Second test:
Install termcap (mv /etc/termcap2 /etc/termcap).
Modify in /etc/termcap: change xterm-hp to hxterm
(search in /etc/termcap for the word 'xterm-hp',
replace first occurencie to hxterm).
Launch an xterm (but not as root). 
Launch at the command prompt: export TERM=hxterm
Launch at the command prompt: infocmp
(you see, we don't have an hxterm entry in terminfo.
But we have this entry in /etc/termcap.).
In /etc/termcap we have hxterm instead of xterm-hp).
Launch at the command prompt: vi aaa.txt
It does not work ! 'vi' does not read /etc/termcap !
We have an 'hxterm' entry in /etc/termcap but not in
terminfo-database.

You receive an output:
    E558: Terminal entry not found in terminfo
          'hxterm' not known. Available builtin terminals are:
           builtin_ansi
           builtin_xterm
           builtin_iris-ansi
           builtin_dumb
           defaulting to 'ansi'

---------------------------------------------------------------
Resume: it seems, 'vi' does not read /etc/termcap
You must see my comments above in the context of this tests.
I wrote: vi (vim) and libtermcap.so.2 does not read
/etc/termcap.
/bin/vi is dynamically linked with libtermcap.so.2
A program can link a library but does not need to use
all exported functions. In other words, this library 
does not read /etc/termcap.
---------------------------------------------------------------


But if I launch /bin/vi instead of vi, it reads /etc/termcap !!!
Probable reason:
We have a one package: vim.
It is compiled in more steps. Target is always 'vim'. But each time
it is linked with different libraries (and not all *.c filles are compiled/
linked).
/usr/bin/vim is linked with libncurses.
/bin/vi is linked with libtermcap
and vi/vim do the following: in certain cases it launchs yourself
using execvp (probably argv[0] is changed: vi -> vim).
I cannot really go deeply into this but one thing is sure:

'vi'/'vim' should read terminfo, not termcap.
This information is 15 - 20 years old.
'vi'/'vim' should be linked with ncurses in both cases.
I see this as a bug in 'vim'.


Back to your issue: 
We could not reproduce your issue in FEDORA CORE 4 using
new /etc/termcap.
'vim' has probably its own 'resource-file' for colors-definiton.
/etc/termcap for xterm has more capabilities now but they are
not 'wrong'. These are the same capabilities as in terminfo.

I have tested mc, emacs (terminal-version), vi, jove.
All works fine.



I have rebuilt (in FEDORA CORE 4) libtermcap.so.2.8 (including auto-trace ==
including libprinta.a).
Copy this file to the directory /bin.
Then launch at the command promopt ./cfr-printnet (do not care about
foreign-messages). This server receives (via bsd-sockets) libprinta.a messages.
Now, try to launch 'xterm' (we launch 'bash' too).
'bash' reads /etc/termcap. It creates a graphical widget. Press this widget to 
see what happens and to see who link libtermcap.so.
Try to launch vi (not as root) and then /bin/vi.
'vi' does not create 'widget'.
'/bin/vi' creates 'widget'.



Comment 5 Radek Bíba 2005-11-24 11:56:14 EST
FYI, running `vi' actually invokes vim if you're common user, it's an alias
defined in /etc/profile.d/vim.sh.
Comment 6 Petr Raszyk 2005-11-24 12:06:34 EST
Created attachment 121457 [details]
libtermcap.so.2.0.8 (incl. net-autotrace)

Copy this file to the directory /bin.
Comment 7 Petr Raszyk 2005-11-24 12:10:24 EST
Created attachment 121458 [details]
a server (presents app-logs/traces via network)

Launch at the command prompt: chmod 744 ./cfr-printnet
Launch at the command prompt: ./cfr-printnet
Comment 8 Petr Raszyk 2005-11-24 12:17:44 EST
And then launch a xterm and /bin/vi.
Press the 'widget'. Search down. You will find all (and all new) xterm 
/etc/termcap caps.
Comment 9 Petr Raszyk 2005-11-24 12:27:43 EST
We will close this bug as 'NOT A BUG IN TERMCAP'.
Comment 10 Petr Raszyk 2005-11-24 14:28:45 EST
A POST MESSAGE:

Thanks to rbiba@redhat.com
(to find the really issue (vi <--> vim)/(libtermcap/libncurses)).
Comment 11 JW 2005-11-24 17:56:03 EST
(In reply to comment #5)
> FYI, running `vi' actually invokes vim if you're common user, it's an alias
> defined in /etc/profile.d/vim.sh.

FYI this is a bug report about vim-minimal and /bin/vi.
It has nothing to do with the contents of /etc/profile.d/vim.sh

Comment 12 JW 2005-11-24 17:57:34 EST
(In reply to comment #4)
> First test:
> Delete /etc/termcap (mv /etc/termcap /etc/termcap2). 
> Launch an xterm (but not as root). 
> Launch at the command prompt: export TERM=xterm
> Launch at the command prompt: vi aaa.txt

Very clever!
Now try using /bin/vi
Comment 13 JW 2005-11-24 18:02:18 EST
> 'vi'/'vim' should read terminfo, not termcap.
> This information is 15 - 20 years old.
> 'vi'/'vim' should be linked with ncurses in both cases.
> I see this as a bug in 'vim'.

They why does /etc/termcap still exsist and why is it getting tweeked so much if
it should be used?

If using /etc/termcap is a bug then why have people been busing changing
/etc/termcap?

You are all over the place yet essentially nowhere.

Comment 14 JW 2005-11-24 18:06:25 EST
(In reply to comment #10)
> A POST MESSAGE:
> 
> Thanks to rbiba@redhat.com
> (to find the really issue (vi <--> vim)/(libtermcap/libncurses)).

Err, sorry, but I pointed that out first!
But I guess you weren't listening.
Comment 15 Radek Bíba 2005-11-25 02:35:19 EST
(In reply to comment #11)
> (In reply to comment #5)
> > FYI, running `vi' actually invokes vim if you're common user, it's an alias
> > defined in /etc/profile.d/vim.sh.
> 
> FYI this is a bug report about vim-minimal and /bin/vi.
> It has nothing to do with the contents of /etc/profile.d/vim.sh
> 
> 

That was a response to comment #4
Comment 16 Radek Bíba 2005-11-25 02:37:08 EST
(In reply to comment #14)
> (In reply to comment #10)
> > A POST MESSAGE:
> > 
> > Thanks to rbiba@redhat.com
> > (to find the really issue (vi <--> vim)/(libtermcap/libncurses)).
> 
> Err, sorry, but I pointed that out first!
> But I guess you weren't listening.
> 

That's it! I'm not really interested in your quarrel.

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