Just wondering if anyone can replicate this issue....
On CentOS 5.2, using vim 7.0.237, I'm having a consistent issue across all my centos boxen.
if I try and access the help files direct (as root), such as ":help tutor" I get:
"usr_01.txt.gz" [readonly][noeol][converted] 11L, 4393C E434: Can't find tag pattern Press ENTER or type command to continue
If I press enter, it shows me what appears to be the output of a binary.
looking at that top line, it appears as if the help files are compressed, and it can't read the tags within them. Is there a satellite package I need to unpack or enable the ability for vim to decipher these?
If I just type ":help" the status line reads:
"help.txt" [readonly] 214L, 7883C
which is ok, and the text file is displayed correctly.
Under Fedora 9, doing a ":help tutor" works correctly, and the status line reads:
"usr_01.txt.gz" [readonly][noeol] 11L, 2914C
Note the different tag on the centos boxen "[converted]"..
Also, /usr/share/vim/vimxx/doc/ seem to be pretty similar (given that Fed9 is vim7.1 and CentOS is 7.0).... even the tags file looks ok on both ends:
Fed9: $ grep tutor tags sql-completion-tutorial sql.txt.gz /*sql-completion-tutorial* tutor usr_01.txt.gz /*tutor* vimtutor usr_01.txt.gz /*vimtutor*
CentOS 5.2: # grep tutor tags sql-completion-tutorial sql.txt.gz /*sql-completion-tutorial* tutor usr_01.txt.gz /*tutor* vimtutor usr_01.txt.gz /*vimtutor*
On Wed, 17 Dec 2008, Spiro Harvey wrote:
Just wondering if anyone can replicate this issue....
On CentOS 5.2, using vim 7.0.237, I'm having a consistent issue across all my centos boxen.
Is it me, or do you have a newer vim than CentOS is shipping ?
[root@rhun ~]# rpm -q vim-common vim-common-7.0.109-4.el5_2.4z
Is it possible you messed something up yourself ?
On Wed, 17 Dec 2008, Dag Wieers wrote:
On Wed, 17 Dec 2008, Spiro Harvey wrote:
Just wondering if anyone can replicate this issue....
On CentOS 5.2, using vim 7.0.237, I'm having a consistent issue across all my centos boxen.
Is it me, or do you have a newer vim than CentOS is shipping ?
[root@rhun ~]# rpm -q vim-common vim-common-7.0.109-4.el5_2.4zIs it possible you messed something up yourself ?
And before everyone gets on top of me for being rude. I can confirm this happens on 7.0.109 as well. Apparently it cannot handle zip files ?
Is it me, or do you have a newer vim than CentOS is shipping ? [root@rhun ~]# rpm -q vim-common vim-common-7.0.109-4.el5_2.4z Is it possible you messed something up yourself ?
And before everyone gets on top of me for being rude. I can confirm this happens on 7.0.109 as well. Apparently it cannot handle zip files ?
well, that is interesting. I have my own repos for our in-house software, but none of that is vim. all my vim installs are from standard centos packages..
# rpm -qa | grep vim vim-minimal-7.0.109-4.el5_2.4z vim-common-7.0.109-4.el5_2.4z vim-enhanced-7.0.109-4.el5_2.4z
# vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Nov 25 2008 11:43:45) Included patches: 1, 3-4, 7-9, 11, 13-17, 19-26, 29-31, 34-44, 47, 50-56, 58-64, 66-73, 75, 77-92, 94-107, 109, 202, 234-235, 237 Modified by bugzilla@redhat.com Compiled by bugzilla@redhat.com [snipped extra stuff]
and if I enter the binary just by typing "vim" or "vi" the splash screen tells me: version 7.0.237
the vim and vi binaries are both from different packages and are quite different:
[root@web1 doc]# ls -lad $(which vi) -rwxr-xr-x 1 root root 593160 Nov 26 05:44 /bin/vi [root@web1 doc]# ls -lad $(which vim) -rwxr-xr-x 1 root root 2723516 Nov 26 05:44 /usr/bin/vim
vim comes from vim-enhanced, and vi comes from vim-minimal.
ah, I wasn't as thorough as I thought. :)
"vi" exhibits the faulty behaviour, while "vim" works correctly with the compressed help files..
Dag Wieers wrote:
On Wed, 17 Dec 2008, Dag Wieers wrote:
On CentOS 5.2, using vim 7.0.237, I'm having a consistent issue across all my centos boxen.
Is it me, or do you have a newer vim than CentOS is shipping ?
[root@rhun ~]# rpm -q vim-common vim-common-7.0.109-4.el5_2.4zIs it possible you messed something up yourself ?
And before everyone gets on top of me for being rude. I can confirm this happens on 7.0.109 as well. Apparently it cannot handle zip files ?
Works fine here.
"usr_01.txt.gz" [readonly][noeol] 11L, 2903C
vim-common-7.0.109-5.el5.br.3.x86_64
Ralph
just as a followup, if I ungzip a file, and edit the tags file to reflect the new name, it displays properly.
putting it back returns its state to the regular fubar.
On Wed, 17 Dec 2008, Spiro Harvey wrote:
just as a followup, if I ungzip a file, and edit the tags file to reflect the new name, it displays properly.
putting it back returns its state to the regular fubar.
After looking into this, you can see if it only happens when using 'vi' without an alias to 'vim'. Or does it also happen to 'vim' ?
(Beware that as root 'vi' is not aliased to 'vim', but as a user it is)
You can directly test using:
unalias vi vi -c "h tutor"
and
unalias vim vim -c "h tutor"
I think this is normal behaviour for 'vi' as it does not support gzipped help pages. Seems the case for RHEL too, so it is not specific to CentOS. You might want to to check the same on Fedora too ?
Kind regards,
I think this is normal behaviour for 'vi' as it does not support gzipped help pages. Seems the case for RHEL too, so it is not specific to CentOS. You might want to to check the same on Fedora too ?
yes, it seems you're right.. I just figured that out in another post coming the list's way. :)
and under Fedora as root, it exhibits exactly the same behaviour.
I'm still curious about the discrepencies in the version numbers, does yours come up with conflicting numbers on the splash screen?
On Wed, 17 Dec 2008, Spiro Harvey wrote:
I'm still curious about the discrepencies in the version numbers, does yours come up with conflicting numbers on the splash screen?
I can only confirm that you are right on that one as well :-) Also true for RHEL BTW.
From the vi --debug output it seems obvious that vi reports the highest
included patch in the version. So what I think happened is that Red Hat started off from 7.0.109 and added patches upto 237.
Still confusing though.
on 12-17-2008 9:43 AM Dag Wieers spake the following:
On Wed, 17 Dec 2008, Spiro Harvey wrote:
I'm still curious about the discrepencies in the version numbers, does yours come up with conflicting numbers on the splash screen?
I can only confirm that you are right on that one as well :-) Also true for RHEL BTW.
From the vi --debug output it seems obvious that vi reports the highest
included patch in the version. So what I think happened is that Red Hat started off from 7.0.109 and added patches upto 237.
Still confusing though.
Or at least added a patch that erroneously changed the version label to that version.
From the vi --debug output it seems obvious that vi reports the highest included patch in the version. So what I think happened is that Red Hat started off from 7.0.109 and added patches upto 237.
ok, well, it's convinced me I'm not going slightly mad. :)
Thanks for your help, and to everyone else, thanks for the help and input. Much appreciated.
Hi,
On Tue, Dec 16, 2008 at 22:12, Spiro Harvey spiro@knossos.net.nz wrote:
Just wondering if anyone can replicate this issue....
if I try and access the help files direct (as root), such as ":help tutor" I get:
If I press enter, it shows me what appears to be the output of a binary.
This is a bug long known to me (I never bothered to open a bug report for it though).
"vim" has a plug-in to open compressed files, however in compatible mode (which is the mode used when you call "vi" or if you don't have the alias set) the plug-in is not loaded, so it cannot open the helpfiles properly.
Never found a good workaround other than using "vim" explicitely.
Filipe
On Tue, 16 Dec 2008, Filipe Brandenburger wrote:
Hi,
On Tue, Dec 16, 2008 at 22:12, Spiro Harvey spiro@knossos.net.nz wrote:
Just wondering if anyone can replicate this issue....
if I try and access the help files direct (as root), such as ":help tutor" I get:
If I press enter, it shows me what appears to be the output of a binary.
This is a bug long known to me (I never bothered to open a bug report for it though).
"vim" has a plug-in to open compressed files, however in compatible mode (which is the mode used when you call "vi" or if you don't have the alias set) the plug-in is not loaded, so it cannot open the helpfiles properly.
Never found a good workaround other than using "vim" explicitely.
I just set the alias. Yes I understand all of the don't work as root stuff but when you have to work as root you might as well have all of the best tools for the job.
The easiest way to set the alias is to comment out the following 2 lines in /etc/profile.d/vim.sh
#[ -x //usr/bin/id ] || return #[ `//usr/bin/id -u` -le 100 ] && return
They are lines 2 and 3 in the file as shipped by Red Hat and Centos.
HTH,
-
Dag Wieers -
Filipe Brandenburger -
Ralph Angenendt -
Scott Silva -
Spiro Harvey -
Tom Diehl