I'm really happy that SourceTree has Mercurial embedded. On the odd occasion I would like to run an hg command from the CLI, like
hg status
To which I get
hg: command not found
Can I make modifications to my environment path to get the command line working for the embedded version, or do I have to install and manage a separate instance of Mercurial if I want to accasionally use the command line?
I'm using SourceTree OS X version 1.7.2
(This might be a superuser question, but I thought this community has a better chance of knowing and responding.)
The binary lies within SourceTree's bundle, in the resources-folder and is called hg_local.
/Applications/SourceTree.app/Contents/Resources/mercurial_local
You might want to alias it somewhere else (like /usr/local/bin) and rename it on the go:
ln -s /Applications/SourceTree.app/Contents/Resources/mercurial_local /usr/local/bin
It might be a better idea to use some package manager and install mercurial from their repositories, eg. Homebrew. This can be done within few minutes and you gain easy access to lots of other command line tools you might want.
# First install homebrew, than run this command
brew install mercurial
Related
pandoc-crossref must match the pandoc version, and also only the 3.10.0 release works on OSX Big Sur. Thus, it is not possible to get pandoc and pandoc-crossref running in a conda environment from the official channel or from conda-forge.
I could easily download the matching binaries from https://github.com/lierdakil/pandoc-crossref/releases/tag/v0.3.10.0 and copy them e.g. to the binpath:
$ which pandoc-crossref
/usr/local/bin/pandoc-crossref
$ curl -OL https://github.com/lierdakil/pandoc-crossref/releases/download/v0.3.10.0/pandoc-crossref-macOS.tar.xz
$ tar -xzvf pandoc-crossref-macOS.tar.xz
$ mv pandoc-crossref /usr/local/bin/pandoc-crossref
But I think that is not a clean approach, because conda will not know that I updated the version for pandoc-crossref.
What is a clean approach for updating a package managed by conda from a binary available on Github?
Update Feedstock
I updated it on the Conda Forge feedstock, which is what I regard as the "cleanest" solution.
How does one do that? First, OP had posted a comment on the feedstock in the PR that they wanted merged. This was the appropriate first step and hopefully in future cases that should be sufficient to prompt maintainers to act. In this case, it was not sufficient. So, as a follow up, I chatted on the Conda Forge Gitter to point out that the feedstock had gone stale and had non-responding maintainer(s). One of the core Conda Forge members suggested I make a PR bumping the version and adding myself as maintainer, and they merged it for me. In all, this took about 10 mins of work and ~2 hours from start to having an updated package on Anaconda Cloud.
Custom Conda Build
Otherwise, there isn't really a clean solution for non-Python packages outside of building a Conda package. That is, clone the feedstock or write a new recipe, modify it to build from the GitHub reference, then install that build into your environment. It may also be worth uploading to an Anaconda Cloud user account, so there is some non-local reference for it.
Pip Install (Python Packages Only)
In the special case that it is a Python package, one could dump the environment to YAML, edit to install the package through pip, then recreate the environment.
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 have following Problem.
I want to build Qt5 by my own, to be able to use it with Visual Studio 2012. I followed the instructions in the Qt Wiki.
My problem is that when I try to call init-repository
perl init-repository
I get following error:
Hint: Make sure that Perl is added to the path in front of git since that ships an outdated version (Perl 5.8), which will cause the scripts to fail.
This is because the with git shipped perl version is 5.8.8. It doesn't matter, that I have the newest version installed.
Can someone tell me how to update my perl version inside git, to be able to build Qt5?
Regards
It sounds like you are working on Windows, I assume with some recent version of msysgit.
If you are using the shell that comes with msysgit, then it is likely that the shell has modified your PATH variable to put /bin ahead of /c/path/to/new/perl. You can check this by opening the shell and running echo $PATH or even which perl.
To make the shell use you 'new' perl, you can try the following:
export PATH=/c/path/to/new/perl:$PATH
I have a Linux server that has no access to the internet (access is prevented by a firewall). I would like to install a new Perl. What are my options and what is the best way to do this? The system Perl (included in OS installation) must remain unchanged.
I have been using perlbrew and I think it is the best way to do an online installation. But all the steps involved in perlbrew seem to require internet access: you download it from the net, it downloads new Perl versions from the net etc. and I haven't found a glue how to make it work offline.
If perlbrew is out of question I could build Perl from source into a custom location on the server. I assume that this could end up being complicated, time-consuming and error-prone. And every time I update Perl I have make a new build manually.
There can also be other ways to install that I'm not currently aware of. And of course I could stick with the system Perl but it is an outdated version and I'm already using the new syntax features. Or I could start negotiations to change the firewall policy to allow internet access for perlbrew.
But all the steps involved in perlbrew seem to require internet access
Not if properly configured.
To install perlbrew itself off-line, install the App-perlbrew dist. Following its dependencies manually is a chore, so instead prepare a MiniCPAN mirror (with -p to include Perl dists), take it over to the target machine and configure CPAN to use the local mirror. Run cpan App::perlbrew to install.
After perlbrew is installed, run its mirror command to configure a CPAN mirror into $PERLBREWROOT/Config.pm. Edit this file to change it to the local MiniCPAN mirror. Drop Perl dist tarballs into $PERLBREWROOT/dists/.
Be aware that compiling Perl requires a working C compiler toolchain, and optionally the development files for libdb (BerkeleyDB) and gdbm. (Read the INSTALL file once over, even though perlbrew's autoconfiguration and Perl's configure.SH defaults hide these details from you.)
The compiler toolchain is probably much more difficult to procure off-line, unless the OS installation has already been used before for compiling other C stuff.
There's nothing that special about perlbrew. If you aren't going to use it to download the Perl sources, it's not saving you that much. Once you have the Perl sources, you just need to configure and install it:
% ./Configure -des -Dprefix=/path/to/installation
% make install
Once done, everything for that Perl is under that installation path.
I dislike perlbrew mostly because it hides from people how amazingly simple this task is so they feel like they can't do it on their own.
Have you considered attacking it from a different direction? Keeping this up-to-date is going to be a pain if you have to request internet access each time. Likewise, if you've missed out/misconfigured any packages in your CPAN mirror it's difficult to correct once you're actually trying to use them.
Perhaps just build a small VM with a cut-down linux + perl + modules. Keep that up-to-date at your end and just take the whole lot in on a USB stick. You'd have a known-working easy-to-setup installation.
What I personally do is using git checkout when I'm offline (and not on vacation). Once you have the whole git work directory, it's trivial to build any released version by checking out the tags:
git checkout v5.17.4
git clean -f # cleanup previously compiled .o files etc
sh ./Configure ...
Depending on how you can transfer files to your host, this can be handy, since you you can also setup a private git repo there so other computer can git push new commits to there.
I'm using perlbrew and I would like to install the latest bioperl version. Should I use cpanm or git?
If git - do I just install as usual (AKA git clone ... then make and build), or should I do anything special?
UPDATE
Specifically, I'm not sure I understand the following expert from BioPerl Using Git manual:
Tell perl where to find BioPerl
(assuming you checked out the code in
$HOME/src; set this in your
.bash_profile, .profile, or .cshrc):
bash: $ export PERL5LIB="$HOME/src/bioperl-live:$PERL5LIB"
tcsh: $ setenv PERL5LIB "$HOME/src/bioperl-live:$PERL5LIB"
Why is this necesary?
UPDATE 2
Simply exporting the bioperl cloned dir does not effect all the bp_***.pl scripts (which are usually found under /usr/bin/ after a normal Build installation).
I also tried to build from the cloned dir after switching to the correct perl version using perlbrerw, but then it runs cpan shell to install some dependencies which does not seem to work well with perlbrew (as opposed to cpanm).
So, my question remains...
Thanks!
The latest BioPerl is always going to be on GitHub, so git's your answer there. Whether or not you want bleeding edge is another story, but after following the BioPerl mailing list for some time I get the feeling that the developers are more likely to say "install from GitHub" if you have any problems with BioPerl, especially since the most recent version on CPAN is from 2009. There has been a lot of development since then.
As for installing it, I don't see why you couldn't just go ahead and do the standard git clone ... make/build dance once you're using your perlbrew perl, as that's kind of the point of perlbrew. :-)
Update for question update: The blurb about setting PERL5LIB is there because presumably BioPerl doesn't need to be built once you've cloned it via git; it's ready to use straight out of the box. Assuming you haven't cloned it into a directory in #LIB, you need to tell Perl where to find it. You would have to do this whether or not you are using perlbrew.
Essentially the process goes like this:
Clone BioPerl from GitHub.
Make sure you're using your perlbrew-installed Perl.
Set the PERL5LIB environment variable as per the BioPerl instructions.
Run perl -MBio::Perl -le 'print Bio::Perl->VERSION;' to make sure you're using the BioPerl you just checked out.
Looking at the sourcecode, #4 should print out 1.006900, I think (or maybe 1.6.9, I can never keep Perl version numbers straight).