+++ 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 on 2005-11-23 06:25 EST -- Please change: How reproducible: Always -- Additional comment from praszyk 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 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.
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?
Reassigning to proper component owner...
A mail from w203198 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
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'.
FYI, running `vi' actually invokes vim if you're common user, it's an alias defined in /etc/profile.d/vim.sh.
Created attachment 121457 [details] libtermcap.so.2.0.8 (incl. net-autotrace) Copy this file to the directory /bin.
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
And then launch a xterm and /bin/vi. Press the 'widget'. Search down. You will find all (and all new) xterm /etc/termcap caps.
We will close this bug as 'NOT A BUG IN TERMCAP'.
A POST MESSAGE: Thanks to rbiba (to find the really issue (vi <--> vim)/(libtermcap/libncurses)).
(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
(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
> '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.
(In reply to comment #10) > A POST MESSAGE: > > Thanks to rbiba > (to find the really issue (vi <--> vim)/(libtermcap/libncurses)). Err, sorry, but I pointed that out first! But I guess you weren't listening.
(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
(In reply to comment #14) > (In reply to comment #10) > > A POST MESSAGE: > > > > Thanks to rbiba > > (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.