I created a symlink:
Then I decided to remove it:
But I can't. What is going on here? I don't want to force the removal as I am afraid to not affect in any way the original. Operating system is CentOS 5.9. Any advice on how to safely remove the symlink are most welcome!
You have a directory /galaxy, and the symbolic link you created is in that directory, /galaxy/galaxy.
To remove the symlink do: rm /galaxy/galaxy
Related
My problem
In the current project I'm working on, I'm not able to initialise gitflow with SourceTree. Can you help?
My version of SourceTree is 2.7.6.
Screenshots
If I try to do
then I have this dialog
But when I confirm, I have the error
I had exactly the same problem. I moved SourceTree to a different directory, and its path contained a space character from one of its parent directories.
As a result, the path to its internal getopt was stored by SourceTree in ~/.gitflow_export (and, indeed, rewritten at every launch) and contained that space without the required quotes.
Removing the space in the directory name solved the issue. If you move SourceTree around, make sure its path contains no space.
/bin/getopt: not a valid identifier suggests an issue with getopt. There were few reported to Attlassian e.g. Is git-flow broken in Sourcetree 2.7.1?
A possible workaround to install getopt by hand as per Post installation setup:
Install GNU getopt via Homebrew:
brew install gnu-getopt
Create a ~/.gitflow_export with the content export FLAGS_GETOPT_CMD="$(brew --prefix gnu-getopt)/bin/getopt".
For git-flow versions prior to 1.4.0-dev.28
Create a ~/.gitflow_export with the content alias getopt="$(brew --prefix gnu-getopt)/bin/getopt".
If you have installed GNU getopt through other means than Homebrew, substitute $(brew --prefix gnu-getopt)/bin/getopt with the location of the GNU getopt file.
Apologies in advance. Managed to resolve the issue for myself with a hack.
My solution was based on the above observations. (Which I tried)
The issue was the space in the name Sourcetree 3 (in my case)
In the Applications folder I selected the Icon for launching the application and removed the space. Gitflow is now working.
Sorry if you are horrified by my crude hack but it works and I do not have more time to invest into this issue.
What is the easiest way to install Perl under $prefix/lib/perl5/perl5.X instead of $prefix/lib/perl5/perl5.X.Y? In current scheme all binaries linking against libperl.dylib stop working when I replace the old version of Perl with a new one (because a theoretically ABI-compatible library gets moved to a different location).
The Configure file contains
case "$installstyle" in
*lib/perl5*) set dflt privlib lib/$package/$version ;;
and $version is set to 5.X.Y, but I'm not sure how to safely fix that path without breaking anything.
As mob has already suggested, don't try to change where perl is installing, instead just setup a symlink to point to the version that you want to use.
ln -s $prefix/lib/perl5/perl5.X $prefix/lib/perl5/perl5.X.Y
However, I believe you probably could use an introduction to perlbrew. perlbrew is a tool to manage multiple perl installations in your $HOME directory. This would enable you to install a new version without risking your other development environments, and switch between versions of perl seamlessly.
mv $prefix/lib/perl5/perl5.X.Y $prefix/lib/perl5/perl5.X
ln -s $prefix/lib/perl5/perl5.X $prefix/lib/perl5/perl5.X.Y
?
I am using Ubuntu 12.04. I have installed doxygen 1.8.3.1 using make install.
I would like to uninstall the doxygen built by make, but I don't find any way to do it using make (uninstall or clean...).
In the Makefile there is no reference to uninstall it the software. :(
Unfortunately I can't use the sudo apt-get remove doxygen because it wasn't an installed. :(
I don't find anything related on the internet.
Can anyone help me, please?
Thank you in advance,
Fabiola
There is no "uninstall" target. You need to do a "rm" be hand. If you used the standard prefix path "/usr/local" then
rm /usr/local/bin/doxygen
rm /usr/local/man/man.1/doxygen.1
(more if you install the docs are wizard). Depend on the user used for install, you need sudo to do it.
I know this question is old, but since it is the first result in google I would like to share another way of uninstalling Doxygen built from source. In the build directory where you've ran make there should by a file name install_manifest.txt. That file contains paths to files that were installed using make install command. All you need to do is to run the following command:
sudo xargs rm < install_manifest.txt
Of course this assumes that you've kept the build directory or at least the install_manifest.txt file. If not you need to remove the files by hand as somebody already suggested.
I need to un-install a version of Perl which was built from source. The directory from which it was built exists. However I didn't find a make target called 'uninstall'. The Perl version I have is 5.12.2 and is installed on a Fedora distributed Linux.
Because perl has no 'make uninstall' target, you need to remove the files manually. The best way to do this is to get a complete list of files installed. To do that you need to:
Create a temporary directory, e.g. /usr/local/src/temp/perl
Edit the Makefile in your original perl source directory (hopefully you didn't delete it) and add the path from step 1 above to the beginning of all install lines (e.g. bin = ..., scriptdir = ..., INSTALLPREFIXEXP = ...)
Run make install
Navigate to your temp directory and run: find . -type f > filelist.txt
Edit this file and make sure you actually want to delete eveything in there (you will screw up your system real bad if you mess this up)
Run cat filelist.txt | xargs rm
Manually delete the perl5 library directory (usually at something like /usr/local/lib64/perl5 - you can find it in the filelist.txt file)
That's it, all gone.
Next time isolate it in a separate directory and just symlink it :-)
If the Perl is installed in its own directory - say /opt/perl/v5.12.2 - and was built from source, then the 'ultimate sanction' works well:
rm -fr /opt/perl/v5.12.2
I almost always build my own Perl; I always build my Perl so it installs in its own, unique directory; when I finally get around to removing it, this is how I do it.
A method that
Assumes installation in a subtree of /usr/local,
doesn't require the build directory
is slightly less accurate
Run the following command,
sudo find /usr/local -name '*perl*' -or -name 'pod2*' -or -name '*cpan*' -exec rm -rf {} \;
If you still have the source, you can remove it by using:
make uninstall
while you are in the source directory.
Btw, I sugggest to use checkinstall next time while installing from source.
See this
If you (as you said...) dont have a target uninstall, then you will probably will have to remove it by hand.
I installed a new version of emacs (new for me). I didn't want to overwrite the stock copy so I put it in a group-readable directory ~admin/sw. I point my $PATH there and I'm able to pick it up, but when I run ~admin/sw/bin/emacs I get a whole bunch of warnings and errors:
Warning: arch-dependent data dir (/usr/local/libexec/emacs/23.1/x86_64-unknown-linux-gnu/) does not exist.
Warning: Lisp directory `/usr/local/share/emacs/23.1/site-lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/23.1/lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/23.1/leim' does not exist.
When I compiled emacs I did it as: make install prefix=~admin/sw. All of those directories do exist but they exist at ~admin/sw/share/...
How can I configure my environment so that emacs looks there for the files? Thanks!
Rather than
make install prefix=~admin/sw
try:
./configure --prefix=~admin/sw
make
make install
This may require an absolute path.
Do you have a .emacs file around ( perhaps dating back to a previous install ) that could have the wrong path in it?
Before I did ./configure - -prefix=CUSTOMPATH > make > make install, I also replaced all instances of /usr/local in src/epaths.in to CUSTOMPATH.
configure script used src/epaths.in to generate src/epaths.h which is used in make install.