Redhat Linux has crippled Vim
howard Schwartz
trying to work with vim on a Redhat Linux distribution at a university. By
default, apparently (version 7.3) is severely crippled with minus signs next
to almost every feature one can think of -- command line completion, the
ability to format comments -- etc. They call it a ``minimal'' version.
Redhat's ``enhanced'' version is not - It adds one or two trivial features.
I tried building a decent vim from src.rpm, but had the usual nightmare:
libraries were the wrong version, files were in the wrong directory, one had
to be root, etc. etc. I tried to build vim from regular source, and laughed at
the vim.org claim that ``building vim is easy''.
I have never found building a complex binary from source ``easy'' unless one
did it on one's own OS, and had full knowledge of the locations and
requirements that the original author intended -- dispite the claims of gnu's
autoconf etc.
Any ideas why Redhat wants to convert vim back to the limitations of the old
vi?
any ideas where to find an rpm package of vim for fedora or linux that is not
severely crippled?
OK - that is my tirade. Any suggestions?
Reid Thompson
> OK - that is my tirade. Any suggestions?
Reid Thompson
> the vim.org claim that ``building vim is easy''.
Dotan Cohen
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
You need to install "vim" or "vim-full" or some such package. CentOS
and Ubuntu do the same thing, it is not big deal.
--
Dotan Cohen
Dotan Cohen
# yum install vim-enhanced
Dotan Cohen
According to yum:
: Install the vim-enhanced package if you'd like to use a
version of the
: VIM editor which includes recently added enhancements like
: interpreters for the Python and Perl scripting languages.
You'll also
: need to install the vim-common package.
Ben Fritz
On Jan 26, 10:31 am, howard Schwartz <howard...@gmail.com> wrote:
> This may not be the place to ask about this but: I recently had the misery of
> trying to work with vim on a Redhat Linux distribution at a university. By
> default, apparently (version 7.3) is severely crippled with minus signs next
> to almost every feature one can think of -- command line completion, the
> ability to format comments -- etc. They call it a ``minimal'' version.
>
> Redhat's ``enhanced'' version is not - It adds one or two trivial features.
>
probably is fairly full-featured and should be able to run in a
console as well.
Steve Hall
>
> Redhat's ``enhanced'' version is not - It adds one or two trivial features.
Better check your :version, vim-enhanced is compiled by redhat with
the "huge" +feature-list. Only the "-" items below are missing from mine:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 21 2011 09:32:10)
Included patches: 1-315
Modified by <bugz...@redhat.com>
Compiled by <bugz...@redhat.com>
Huge version with GTK2 GUI. Features included (+) or not (-):
++builtin_terms +arabic +autocmd +balloon_eval +browse +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +conceal +cryptv +cscope +cursorbind
+cursorshape +dialog_con_gui +diff +digraphs +dnd +emacs_tags +eval
+ex_extra +extra_search +farsi +file_in_path +find_in_path +float
+folding +fork() +gettext +iconv +insert_expand +jumplist +keymap
+langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse +mouse_dec +mouse_gpm +mouse_netterm
+mouse_xterm +mouseshape +multi_byte +multi_lang +netbeans_intg
+path_extra +perl +persistent_undo +postscript +printer +profile
+python +quickfix +reltime +rightleft +ruby +scrollbind +signs
+smartindent +startuptime +statusline +syntax +tag_binary
+tag_old_static +terminfo +termresponse +textobjects +title +toolbar
+user_commands +vertsplit +viminfo +virtualedit +visual +visualextra
+vreplace +wildignore +wildmenu +windows +writebackup +X11 +xim
+xsmp_interact +xterm_clipboard
-ebcdic -footer -hangul_input -lua -mouse_jsbterm -mouse_sysmouse
-mzscheme -python3 -sniff -sun_workshop -tag_any_white -tcl -xfontset
-xterm_save
--
Steve Hall [ digitect dancingpaper com ]
howardb21
`minimal'), which I did install. The so called `inhanced' had I
believe only 2 extra features, and still lacked such simple
conveniences as command line history. Apparently, in redhat one only
gets a decent set of features compiled, if one installs the graphics
version of gvim. For my blind friend, who needs the text version, this
is not an option.
On Jan 26, 9:21 am, Dotan Cohen <dotanco...@gmail.com> wrote:
> > This may not be the place to ask about this but: I recently had the misery
> > of trying to work with vim on a Redhat Linux distribution at a university.
> > By default, apparently (version 7.3) is severely crippled with minus signs
> > next to almost every feature one can think of -- command line completion,
> > the ability to format comments -- etc. They call it a ``minimal'' version.
>
> > Redhat's ``enhanced'' version is not - It adds one or two trivial features.
>
> > I tried building a decent vim from src.rpm, but had the usual nightmare:
> > libraries were the wrong version, files were in the wrong directory, one had
> > to be root, etc. etc. I tried to build vim from regular source, and laughed
> > at the vim.org claim that ``building vim is easy''.
>
> > I have never found building a complex binary from source ``easy'' unless one
> > did it on one's own OS, and had full knowledge of the locations and
> > requirements that the original author intended -- dispite the claims of
> > gnu's autoconf etc.
>
> > Any ideas why Redhat wants to convert vim back to the limitations of the old
> > vi?
>
> > any ideas where to find an rpm package of vim for fedora or linux that is
> > not severely crippled?
>
> > OK - that is my tirade. Any suggestions?
>
> > --
> > You received this message from the "vim_use" maillist.
> > Do not top-post! Type your reply below the text you are replying to.
howardb21
> what steps did you take and what errors did you get (for compiling and configuring the vim source)
I installed the source and tried various work arounds to the standard
make. But this is a large, networked computer system maintained by a
major university. They are not about to give one of their ordinary
usuers root priviliges. And one needed root permissions to run make,
or the compiler. Yes I can ask them to do it for me, but a previous
request like that failed. We may well have to pressure them on the
grounds of accessibility.
howardb21
provides very very few extra features.
howardb21
not provide features that must be compiled in the basic binary. yes I
was hopeful when I read wht you quote below. But when I installed
`enhanced' I stil saw minus signs by almost all of the features. e.g.
,-clientserver -clipboard -cmdline_compl -cmdline_hist -cmdline_info -
comments
-cryptv -cscope -cursorshape -dialog -diff -digraphs -dnd -ebcdic -
emacs_tags
-eval -ex_extra -extra_search -farsi -file_in_path -find_in_path -
folding
-footer +fork() -gettext -hangul_input +iconv -insert_expand -jumplist
-keymap
-langmap -libcall -linebreak -lispindent -listcmds -localmap -menu -
mksession
-modify_fname -mouse -mouse_dec -mouse_gpm -mouse_jsbterm -
mouse_netterm
-mouse_xterm +multi_byte -multi_lang -mzscheme -netbeans_intg -
osfiletype
-path_extra -perl -printer -profile -python -quickfix -reltime -
rightleft -ruby
-scrollbind -signs -smartindent -sniff -statusline -sun_workshop -
syntax
-tag_binary -tag_old_static -tag_any_white -tcl +terminfo -
termresponse
-textobjects -title -toolbar -user_commands -vertsplit -virtualedit -
visual
-viminfo -vreplace +wildignore -wildmenu -windows +writebackup -X11 -
xfontset
-xim -xsmp -xterm_clipboard -xterm_save
I really suspect, with redhat or fedora -- if one wants a decent set
of features in the main executable one must compile it oneself, or
find somebody who did for fedora or redhat. I was hoping one of you
could pointment me to such a package. Otherwise, I will need to
install a whole fedora Os on my pc, so I can be root, compile the
thing. and then transfer to the university computer.
On Jan 26, 9:37 am, Dotan Cohen <dotanco...@gmail.com> wrote:
howardb21
faculty member who uses telnet and a text based screen reader. He
needs vim, and can not use gvim.
howardb21
On Jan 26, 3:39 pm, Steve Hall <digit...@dancingpaper.com> wrote:
>
> > Redhat's ``enhanced'' version is not - It adds one or two trivial features.
>
> Better check your :version, vim-enhanced is compiled by redhat with
> the "huge" +feature-list. Only the "-" items below are missing from mine:
one gets the `huge' features. But my friend needs vim, not gvim (see
other posts). I would have thought the gui version would include vim,
as it does for ms windows. But it does not.
You must be in a graphical environment to get the huge features. As
far as I can tell the standard versions are: minimal, enhanced, and gui
Christian Brabandt
On Fr, 27 Jan 2012, howardb21 wrote:
> Yes there is. But my friend who uses this university computer is blind
> faculty member who uses telnet and a text based screen reader. He
> needs vim, and can not use gvim.
The graphical package should also contain a text binary. If not, simply
link gvim to vim and it should run on the console.
regards,
Christian
Jacobo de Vera
>
> I installed the source and tried various work arounds to the standard
> make. But this is a large, networked computer system maintained by a
> major university. They are not about to give one of their ordinary
> usuers root priviliges. And one needed root permissions to run make,
> or the compiler. Yes I can ask them to do it for me, but a previous
> request like that failed. We may well have to pressure them on the
> grounds of accessibility.
>
You can install it in your home directory, you don't need root
permission for that.
When you run the configure step, there is a --prefix option that you
can set to a directory that you can write to, e.g., somewhere in your
home directory, say /home/howardb21/myruntime, and then after your
usual make && make install you'll have your vim binary under
/home/howardb21/myruntime/bin, which you'd want to add to your PATH.
Regards,
--
Jacobo de Vera
http://www.jacobodevera.com
Ben Fritz
Unix-like systems. There's even a command to launch the GUI from a Vim
running in the console, :gui.
I thought there was a command-line argument to gvim which would cause
it to run in the terminal, but I can't find it, the closest I could
come was -v, "Start Ex in Vi mode. Only makes a difference when the
executable is called 'ex' or 'gvim'. For gvim the GUI is not started
if possible."
But, simply renaming the executable to vim, or creating a link to gvim
named vim, should work. I couldn't find it explicitly stated in the
help that an executable called "vim" would not start the GUI, but it
is implied at least by the list at the end of :he vim-arguments, which
goes over the default arguments based on executable name.
Tim Gray
>Apparently, in redhat one only gets a decent set of features compiled,
>if one installs the graphics version of gvim.
This isn't an authoritative response by any means, but that's what I
found. My experience is with an RHEL 5.3 system where I let the
subscription expire. I found it easiest to just download the source
from mercurial and build it myself. It was pretty straightforward,
though I do have administration privileges on the machine. While I did
build the GUI version, it runs perfectly fine from the console, which is
how I use it most of the time.
Dotan Cohen
> Again I say onto you all - on RedHat `enhanced' is not enhanced. It
> provides very very few extra features.
>
From your earlier email you mention 7.3, that sounds like RHL, not
RHEL. That version could be 8 or 10 years old, what VIM version is on
there? I do not know how recent of a CentOS or Fedora binary you could
run on that, but you won't break anything by trying.
David Ohlemacher
Here is what I have with details of how I got it just using the repo rpms. I did have to alias vim-->vimx. Hope this helps.
ops@ida:~:114# yum list | grep vim
vim-X11.i386 2:7.0.109-7.el5 installed
vim-common.i386 2:7.0.109-7.el5 installed
vim-enhanced.i386 2:7.0.109-7.el5 installed
vim-minimal.i386 2:7.0.109-7.el5 installed
ops@ida:~:115# whereis vimx
vimx: /usr/bin/vimx
ops@ida:~:116# file /usr/bin/vim
vim* vimdiff@ vimtutor* vimx@
ops@ida:~:116# file /usr/bin/vimx
/usr/bin/vimx: symbolic link to `gvim'
ops@ida:~:117# whereis gvim
gvim: /usr/bin/gvim /usr/share/man/man1/gvim.1.gz
ops@ida:~:118$ vimx --version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 5 2011 21:34:01)
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-237
Modified by <bugz...@redhat.com>
Compiled by <bugz...@redhat.com>
Huge version with GTK2 GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist
+keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
-netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile
+python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
-sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static
-tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace
+wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact
+xterm_clipboard -xterm_save
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/etc/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_REENTRANT -D_GNU_SOURCE -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -I/usr/include/python2.4 -pthread
Linking: gcc -L/lib -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -L/usr/local/lib -o vim -L/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lselinux -lacl -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -L/usr/local/lib /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -lperl -lresolv -lutil -lc -L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic
. o . . . o o o o
Tony Mechelynck
As other posters have said, on Linux (and, in fact, on all Unix-like
OSes, which means practically everywhere except on MS-Windows), the GUI
executable can also be used in console mode, by invoking it as "vim"
(through a softlink or an alias, or by having that be the actual name of
the executable).
On my system, I compile two versions of Vim:
- a Huge version with GTK2/Gnome GUI and +perl +python +ruby +tcl, named
"vim" with softlinks "view", "vimdiff", "gvim", "gview", etc. linking to
it. It works in console mode or GUI mode depending on how it is invoked;
- a Tiny version with no GUI and with most features compiled out, which
I use mostly as a sanity check that no #ifdef clauses are missing. It is
named "vi". I use it only rarely, but the executable is only 610K
instead of the 3.9M of the other: quite a difference!
If you still want to compile your own Vim (rather than create a softlink
by something like "pushd ~/bin; l, -sv `which gvim` vim; popd", which I
think is easiest andleast error-prone), it is feasible, even on a system
where you have no admin privileges, provided that all necessary
"development" packages are installed (or that you can install them e.g.
in your user space) and that you place the executable in ~/bin rather
than in the default /usr/local/bin. Similarly, you may either place the
runtime files in ~/share/vim/vim73 (or something), or rely on the files
placed by your sysadmin in /usr/share/vim/vim73 (or something), but in
the latter case the final step will be "make installvimbin" rather than
"make install" and in all cases the executable must know -- via the
config arguments -- where its runtime files are to be found. That's (for
version 7.3) the vim73 subfolder of what will appear under "fall-back
for $VIM" near the middle of the output of :version in the build you
compile.
Best regards,
Tony.
--
You're being followed. Cut out the hanky-panky for a few days.
Tony Mechelynck
-----------------------------------^ should be: ln -sv `which gvim` vim
> think is easiest andleast error-prone), it is feasible, even on a system
> where you have no admin privileges, provided that all necessary
> "development" packages are installed (or that you can install them e.g.
> in your user space) and that you place the executable in ~/bin rather
> than in the default /usr/local/bin. Similarly, you may either place the
> runtime files in ~/share/vim/vim73 (or something), or rely on the files
> placed by your sysadmin in /usr/share/vim/vim73 (or something), but in
> the latter case the final step will be "make installvimbin" rather than
> "make install" and in all cases the executable must know -- via the
> config arguments -- where its runtime files are to be found. That's (for
> version 7.3) the vim73 subfolder of what will appear under "fall-back
> for $VIM" near the middle of the output of :version in the build you
> compile.
>
>
> Best regards,
> Tony.
--
Like Jaspar wine and sugar,
It must have blown through someone's feet,
Like those of Caspar Weinberger.
-- P. Opus
Tony Mechelynck
> Thanks for the advice but this did not seem true for me. I did install
> an X-11 version of vim === a binary rpm package. I got gvim and a
> creature called evim which I recall is a vim designed to run like a MS
> windows editor, with no modes.
>
> gvim did not run on console, and evim I did not try since it would hve
> the familiar microsoft menues on top.
>
> Are you claiming that these distributions themselves should come with a
> copy of console vim? Mine did not. Are you claiming that gvim should run
> in console mode? Mine did not. I can revisit this and see if there is
> some switch I do not know to make gvim run as if it were not expecting a
> graphical window.
>
> thanks the the advice. please keep it coming,
>
> howard
>
>
>
I am claiming that, on Linux but not on Windows, if you install gvim,
then set up a symlink named "vim" pointing to it and located early in
your $PATH, invoking this "vim" symlink at a shell prompt will make the
gvim binary run in console mode.
Beware that the order of the arguments of the "ln" command is
unintuitive: target first, then link name. For instance in bash, after
installing gvim, you would do
pushd ~/bin
ln -sv `which gvim` vim
popd
ls -l `which vim`
and it should answer something like
~/bin ~
vim -> /usr/bin/gvim
~
lrwxrwxrwx 1 schwartz users 13 /home/schwartz/bin/vim -> /usr/bin/gvim
(with possible variations depending among others on your login name and
on where RedHat / Fedora installs the gvim binary).
Then invoking "vim" or "gvim" without the quotes at a shell prompt
should run the same executable in both cases, but as a cursesUI program
in console in the first case and as a GUI (forked out of the console) in
the second case (except that when invoked with either --help/-h or
--version even gvim would display something in the console and exit
immediately).
Best regards,
Tony.
--
This is an airconditioned room, do not open Windows.
Christian Brabandt
On Sa, 28 Jan 2012, Tony Mechelynck wrote:
> Beware that the order of the arguments of the "ln" command is
> unintuitive: target first, then link name.
If you think of it as a command, that always needs a target, but does
not necessarily need a link name, then it is not intuitive.
regards,
Christian
--
Michael Henry
The ``ln`` command became intuitive to me when I realized that
its syntax is uniform with that of the ``cp`` command:
Copy source file(s) into destination:
$ cp source destination
$ cp source1 source2 source3 destination
Hard link source file(s) into destination:
$ ln source1 source2 source3 destination
$ ln source destination
Symlink source file(s) into destination:
$ ln -s source1 source2 source3 destination
$ ln -s source destination
With only one source, ``destination`` may be a directory or a
filename. With multiple sources, ``destination`` must be a
directory.
In all of the above cases, the last argument on the right
represents where to create the new item(s). Each new item is
either a copy of an existing file, a hard link to an existing
file, or a symlink to an existing file. At some level, all of
the new items "point back" to the original source. A symlink
points back in the most directly visible way, since the ``ls``
command uses an arrow to show the linkage:
$ mkdir ~/tmp/linkdemo
$ cd ~/tmp/linkdemo
$ touch source
$ ln -s source symlink
$ ls -l symlink
lrwxrwxrwx 1 mike mike 6 2012-01-28 08:06 symlink -> source
In my opinion, this arrow notation is what makes the
command-line syntax seem counter-intuitive, since ``symlink`` is
displayed on the left and ``source`` is on the right. It helps
me to recall that ``symlink`` was created as a (linked) copy of
``source``, so it's pointing back to the original.
Hard links work similarly:
$ ln source hardlink
$ ls -li
13239823 -rw-rw-r-- 2 mike mike 0 2012-01-28 08:06 hardlink
13239823 -rw-rw-r-- 2 mike mike 0 2012-01-28 08:06 source
13239824 lrwxrwxrwx 1 mike mike 6 2012-01-28 08:06 symlink -> source
The ``-i`` flag shows the "inode" number in the first column.
``hardlink`` and ``source`` now share the same inode number,
which means both filenames link to the same underlying stream of
bytes, so they are linked together. For example:
$ echo "Some new text" > source
$ cat hardlink
Some new text
$ diff -s source hardlink
Files source and hardlink are identical
This syntax has the nice feature that you can do wildcard copies
or links in the same way:
Copy multiple pictures to a backup directory:
$ cp ~/pictures/*.jpg /path/to/backup/directory/
Symlink pictures of Snowmen into a separate directory:
$ mkdir ~/tmp/snowmen
$ ln -s ~/pictures/snowman*.jpg ~/tmp/snowmen
Michael Henry
Benjamin R. Haskell
> [...] if you install gvim, then set up a symlink named "vim" pointing
> to it [...]
>
> [...] For instance in bash, after installing gvim, you would do
>
> pushd ~/bin
> ln -sv `which gvim` vim
> popd
Why the pushd/popd? This is more straightforward:
ln -sv `which gvim` ~/bin/vim
--
Best,
Ben
Tony Mechelynck
> thanks for your advice and I was hoping to find it worked. It took a lot
> of looking for find a gvim for X11 that is meant for fedora or redhat.
> Most links of the search rpm engines do not seem to work.
>
> However, with or without a symbolic link or copy, when I run any version of
> gvim i get messages like,
>
> when opening can not open shared library libgtk-1.2.so.0
>
> I guess I have to hunt around for X-11 libraries to see if these puppies
> will hunt?
>
>
>
libgtk-1.2 ? That would mean GTK1, something that is completely obsolete
now, not even supported by its own makers. Vim 7.3 does not support it
either, and that means every version of Vim since 2010-08-15. What
version of Vim did you install? What version of RedHat/Fedora are you
on? What is the version of Vim (the minimal Vim about which you
complained) that comes with it? (The latest version of Vim is 7.3.421 as
of this writing.)
You may have to compile you own after all: see
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
but this would mean making sure that all the appropriate -devel packages
needed to compile Vim are installed (and maybe your sysadmin doesn't
want them installed); or else, try to convince him to install a GUI Vim
on the system (if there isn't one already): then you can set up, as I
showed you earlier, a symlink $HOME/bin/vim pointing to the system gvim.
If you compile Vim yourself, then in addition to the settings mentioned
on the compunix.htm page, you would have to add the following line in
the script to be sourced (not executed) by bash just before the make:
export CONFIG_ARGS='--prefix=$HOME'
in order to install into subdirectories of your home directory.
Best regards,
Tony.
--
Oh Dad! We're ALL Devo!
Tony Mechelynck
> As mentioned the link does not work. But curious. is their some reason
> linking gvim to a name like vim would work, when just renaming gvim to
> vim -- or copying gvim to vim and putting the latter in some directory
> early in one's path would not work?
[...]
No, copying the system gvim to $HOME/bin/vim should work too, but it
would use maybe 3 or 4 megabytes of additional disk space instead of
less than 20 bytes. As for renaming gvim to vim, you cannot do that if
it resides in a directory where you don't have write permissions;
otherwise it should work too � but you wouldn't have a gvim executable
anymore, you would have to invoke the GUI as "vim -g" or create a
softlink gvim -> vim �
Do you mean that when you copy the file accessed by `which gvim` to
$HOME/bin/vim and try to run it it complains about some missing library,
but that running it directly as gvim works correctly (in GUI mode)? That
would be most unusual.
Best regards,
Tony.
--
The seven deadly sins ... Food, clothing, firing, rent, taxes,
respectability and children. Nothing can lift those seven milestones
from man's neck but money; and the spirit cannot soar until the
milestones are lifted.
-- George Bernard Shaw
Jonathan Paugh
I always think of it like this:
$ mv SRC TARGET
$ cp SRC TARGET
$ ln SRC [TARGET]
Tony Mechelynck
Why? Because the link target, as named in the link, is always relative
to the directory of the link. By having that directory current when
creating the link I find I make fewer errors. In this case it doesn't
matter, since the link points to an absolute path; but by making it a
rule never to create links except in the current directory I have found
that when it does matter I "naturally" give the right operands.
Best regards,
Tony.
--
"I had to censor everything my sons watched ... even on the Mary Tyler
Moore show I heard the word 'damn'!"
-- Mary Lou Bax
Tony Mechelynck
> Linux ubunix02.acsu.buffalo.edu 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8
> 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> Vim: minimal:
>
> VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 4 2010 07:21:53)
> 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-237
7.0.237, that source dates back to 1 May 2007 (7 May 2006, as listed, is
the unpatched 7.0), I can't understand why RedHat was still using that
source (more than three years old by then) on 4 August 2010.
>
>
> I believe the version of gvim I tried was 7.0. Im relatively new to the
> world of rpm's for fedora or redhat. What I find is that when I look,
> using phonefind or rpmfind for packages -- I get ones for the wrong
> platform, I get ones with links to ftp sites that do not work. When I go
> to the sites, that version of vim is no longer there. Or I get something
> that might work, I download and install it to the university computer.
> And most often it does not work for one reason or another.
Anyway, IIUC the RPM itself says where (as absolute paths) its contents
are to be unpacked; the install should be run as root; if you don't have
admin privileges, and try to install an RPM archive, it will probably
fail with "permission denied" or somesuch.
>
> In sum, even if I know all the parameters to look for, I do not know how
> to find a corresponding package that will really work. And they have
> arranged it so I do not have permission to run make, configure, install,
> or the gcc compiler.
tough luck.
Well, I could send you a .tar.gz or .tar.bz2 of the Vim version I'm
currently using (on openSUSE Linux 12.1, Huge 64-bit version with [among
others] +gui_gnome +gui_gtk2 +perl +python +ruby +tcl) but there's no
guarantee that the libraries it needs will be found on your system, or
even that if they _are_ installed (and with the versions it needs) they
will be found where the program looks for them.
>
> I was very luckly, for instance, to find a workable Pine email client
> for this
> platform, when the people who installed redhat decided to discontinue
> support for Pine (but my friends wanted it).
>
>
>
Could you please use "Reply to List" if your mailer offers it, or at
least "Reply to All" (rather than just "Reply to Author")? I'm just one
user of Vim, and by emailing only me you deprive yourself of possible
answers from other people. One reason I've been systematically adding
back the list when replying to you is to allow other people to correct
me if and when I make a mistake.
Best regards,
Tony.
--
"Really ?? What a coincidence, I'm shallow too!!"
pansz
> This may not be the place to ask about this but: I recently had the misery
> of trying to work with vim on a Redhat Linux distribution at a university.
> By default, apparently (version 7.3)
Are you talking about 12+ years old Redhat 7.3? Well, please come back
to 21st century and choose a distribution from this century.
> I have never found building a complex binary from source ``easy'' unless one
> did it on one's own OS,
It should be easy, if you know your distribution well enough. For
example: in ubuntu all you need is to do "sudo apt-get build-dep vim"
then everything need to compile vim will be installed and you can
download any version of vim source code (prefered) and compile them,
it is as easy as type: make
For Redhat, you need to find the equivalent command of "sudo apt-get
build-dep vim", and I think there should be one.
> Any ideas why Redhat wants to convert vim back to the limitations of the old
> vi?
It seems that most major "big" distributions tend to ship with
crippled vim by default. It does not hurt for me, because I'll always
compile my own.
Tim Chase
> limitations of the old vi?
I know several distributions install vim-tiny (or its minimal
counterpart) as a way to pack as much power as possible in as
little disk space as possible. Consider dedicated routers and
old machines where disk & RAM are actually tight resources. The
assumption is that, if you want to get such a system up and
running, and need to edit config files in-situ, you don't want to
give up the standard. If you have a beefier machine, you can at
least get your system up and running with the minimal version and
then install vim-kitchen-sink for actual editing.
And lest you think I'm joking, I've done some Debian installs on
machines with 32MB of RAM (I think...it might have been less)
where vim-tiny was usable and using vim-full made me groan. It
was still usable, but it would occasionally trigger swapping if I
didn't take precautions to launch it without certain features.
-tim