I have a version of SVN on my system in /usr/bin/svn. This is too old to use with some repositories so I compiled a newer version in /home/user/built/bin/svn which works fine. I added this to my PATH so it should be run first.
Typing
which svn
produces
/home/user/built/bin/svn
however typing
svn --version
reveals that it us using the old version still. if I run
/home/user/built/bin/svn --version
then the correct version is displayed.
Since the custom version is first in my $PATH, and which lists it first why is the older version being invoked when I run svn? I thought which used your $PATH to find executables in the same fashion as the shell?
Use
type svn
to figure out (a) what it is, (b) where it is or what its definition is. Also check that PATH really contains what you think it does
echo $PATH
Type gives:
type svn
svn is hashed (/usr/bin/svn)
Running
hash -r
has now fixed the problem!
Credit to the OP
You sure you don't have a symbolic link to svn somewhere else in your path?
Related
I apologize if this seems basic but I'm new to linux and not really sure how to proceed. My current git version is 1.7.1 and is located in /usr/bin/git but a newer version of git (1.8) is now available in /usr/src/git/bin/git. How do I make git use this version by default as opposed to the 1.7.1 version?
You have to make sure to call the right executable. This can ben done by explicitly calling /usr/src/git/bin/git instead of git. Of course this would be annoying to type all the time, so you can either make git an alias for that path by adding the line
alias git=/usr/src/git/bin/git
to your .bashrc, or add the directory /usr/src/git/bin to your binary search path by adding the line
export PATH="/usr/src/git/bin:$PATH"
To test that the other git installation searches for the core binaries in the right place, you can check the output of git --exec-path.
I'm trying to compile a piece of software in my home directory (OpenMPI). One of the build dependencies (autoconf) installed on my system is not the newer version asked for by the OpenMPI autogen script. I compiled and installed the newer version of autoconf in my home directory.
Is there anyway for the binary installed in my home directory to "override" the version installed on the system for my session?
I tried setting an alias which works via command line but not for the script used to generate the configure script.
Add the path to the binary you want to override to your $PATH environment variable.
Like PATH=/path/to/binary:$PATH ./compile
Your added path will then be looked up first when trying to find the compile command. It will only be valid for that execution and will not remain after command has returned. You can use export PATH=/path/to/binary/:$PATH and it will be saved for that session.
EDIT: As Eric.J states, you can use which compile which will output the path to the command, just to make sure it's the right one.
You can change the PATH environment variable so that your home directory appears before the system directory, e.g.
PATH=$HOME/bin:$PATH
You can then use the which command to ensure the correct binary is being picked up.
I just installed VCSCommand and I'm getting an error of "No suitable plugin" whenever I try to run a command. I have a filed loaded in Vim that is in a directory with a mercurial repository.
I found some explanations that the "No suitable plugin" error may be displayed if you're not in a "working directory", which I took to mean that the file you're editing should be in a "working directory" of files checked out from the repository. The problem may that (as a new user to Hg) I don't grok Mercurial properly. The file I'm editing is in a directory where I created an Hg repository just to track my local changes. Commands I issued were 'hg init', then 'hg add' and I've been using 'hg commit', 'hg log', and 'hg diff' happily since. Is this directory not a "working directory" of the repo? Assuming this is the problem, how do I "checkout' the files from the hg repo into a working directory?
Or maybe the above isn't the problem with the "No suitable plugin" error at all. I do have the vcshg.vim file in the correct plugin directory, so the plugin is there.
Thanks, any help appreciated.
UPDATE: Just in case my use of mercurial was the problem I tried creating a 'clone' of my main mercurial repo and editing files in the clone. Still get same 'No suitable plugin.' message.
ALSO: I left out of original message that I'm running on Windows, and I think I've tracked things down to improper quoting of escape codes in strings. Will provide further update once I get full resolution.
I did get VCSCommand going fine. I think the issue had nothing to do with Mercurial, rather it had to do with problems in VCSCommand with quoting of system commands on Windows. At least that was the major problem.
To get VCSCommand working I first made sure that the variable b:VCSCommandVCSType was set to 'HG'. It was not getting set for some reason and that was why I was getting the 'No suitable plugin" error.
Second, I had to modify a line in vcshg.vim. The s:Executable() function consists of a one line 'return . . . ' function. The shellescape() wrapper around the system call was quoting improperly; after I removed that it works just fine. (Same problem may exist in the vcsXX.vim files for systems other than Mercurial, I haven't checked that.)
I think this quoting problem exists only on Windows, and may have cropped up because the main developer doesn't have a Windows machine to test on. . . .
First to answer the "working directory" question: your repository is your working directory. Unlike cvs/svn, you do not need to checkout files to edit. You just edit.
(FYI hg aliases its update command to checkout and co to help svn users, but hg update is a very different animal.)
Without knowing your complete environment (platform, vim installation, etc.), I can only guess that the "No suitable plugin" error is due to your VCSCommand files not in the right place. I tried its latest version 1.99.42 with my ancient vim 7.2 on cygwin by cp VCSCommand/plugin/* ~/.vim/plugin/, vim a file in an hg repo, then :VCSStatus shows me the correct result.
If you have other VCSs that VCSCommand supports (cvs, svn, svk, git, bzr), try it in one of their repositories and see if you get the same error. If you do, then it's definitely a VCSCommand installation problem.
I've installed a newer version of svn on my system in ~my/home/bin and put the path to it.
So now from command line a newer version of svn is used instead of the old one, located in /usr/bin/.
However svnant keeps using an older svn in /usr/bin.
How can I tell svnant to use a newer svn?
As seen there svnant does not always uses the executable : http://subclipse.tigris.org/svnClientAdapter.html
1st-JavaHL native (JNI) subversion library (http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/)
2nd-JavaSVN (pure Java) subversion API implementation (http://tmate.org/svn/)
3rd-svn(.exe) command line client wrapper
For the first too you would have to upgrade the jar.
If it really uses the executable you should try putting your executable in the path first before the other svn exe or linking it to /usr/bin
ln -s /home/yourself/bin/svn /usr/bin/svn
You may want to do something like:
mv /usr/bin/svn /usr/bin/svn_old
ln -s ~/your/home/bin/svn /usr/bin/svn
So you have a copy of the old one if you need it, while linking the currently used binary to your new version.
Add your new svn path to java.library.path
I'm getting "skipping XXX: it is not a regular file" every time I run ctags -R XXX. For one reason or another, ctags on Cygwin isn't recursing directories. Surely, I must be doing something stupid.
Whenever I try the de-facto standard ctags -R in my project root, it complains that I didn't specify any input files. When I specify a directory, it seems to think its a file.
I'm a tad stumped. I installed a fresh Cygwin build last week from scratch. I installed everything. I rarely use Cygwin. ctags works perfectly on all my BSD, Linux, Mac and Solaris boxes.
I thought Perforce's read-only permissions might have been the culprit, but chmod 777 changes nothing.
Any ideas? Should I recompile from source?
As is currently being discussed on the Cygwin mailing list, the xemacs-tags and ctags packages both install /bin/ctags. The behaviour you're seeing is from the xemacs version.
The developers will sort it out, although that may take a little while. In the meantime, do the following to get Exuberant Ctags (with its working -R option) installed:
Run the Cygwin installer again (download setup.exe again if you need to).
At the package list, search for "tags" and click the "New" column for both "ctags" and "xemacs-tags" until they say either "Skip" or "Uninstall" (one's under "Devel", the other under "Editors".
Hit "Next".
Once the install has completed, click "Back" instead of "Finish" (if you do this wrong, just restart the installer).
At the package list, select to install "ctags" only. As of today (12 December 2012), that'll specify version 5.8-1.
Click Next and let the install finish.
That'll give you the "ctags" package without the "xemacs-tags" package, and you should be good to go.
I'm getting the same problem, just installed full Cygwin Oct 2012. Downloaded Exuberant Ctags source, compiled, and no more problem.