I would like to use rbenv to control my ruby environment. I followed the basic gethub checkout installation instructions in this site: https://github.com/sstephenson/rbenv#understanding-path
However when i use rbenv command, it says that it isnt found!! When I type
source ~/.bash_profile
(where rbenv path is indicated), into the command line, it says
export: Command not found!!
What a i suppose to do at this point? I need rbenv to install gems because I dont have permission to install (even if i use sudo i need permission). I followed the installation instructions correctly, what is the source of the problem?
info about OS:
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseWorkstation
Description: Red Hat Enterprise Linux Workstation release 6.5 (Santiago)
Release: 6.5
Codename: Santiago
Most of the instructions for installing rbenv are valid for bash and similar POSIX compliant shells. C Shell is not POSIX compliant. This means, among other things, that some commands will not be present or have different names.
So some things to take note of:
You may want to use a file called .cshrc instead of .bash_profile or .bashrc.
The equivalent of export in csh is set or setenv, depending on what kind of behavior you're looking for: http://www.cyberciti.biz/faq/unix-linux-difference-between-set-and-setenv-c-shell-variable/
You may need to run rehash after changing ruby versions: http://blog.hplogsdon.com/multiple-ruby-versions-a-battle-between-rbenv-and-rvm-csh-edition/
To minimize confusion, I'd recommend checking if you can change your default shell to something like bash or zsh.
Related
I would like to make the version of python 2 packaged with MacOS the system default Please show me the recommended approach.
I have installed a Python 3 version from miniconda/anaconda, and my current default Python is:
$ which python
/Users/PatrickT/miniconda3/bin/python
I do not want this to be the default Python anymore. The dilemma is: if I remove conda from the PATH, I can access the Python version packaged with the OS, but then I can no longer access the conda Python...
It sounds like you might want a python version manager, such as https://github.com/yyuu/pyenv
I can't vouch for this specific tool, but there are several similar utilities for ruby (rbenv, rmv) that are great.
OS X (or is it macOS now?) come with an installed version of Python. You almost certainly don't want to mess with that since updates to the OS will likely overwrite your changes. You may want to consider a tool called homebrew for OS X -- it lets you install specific versions of tools like python and manages them externally to the built-in versions.
Edit the .bash_profile
$ nano ~/.bash_profile
1. delete any reference to "export PATH=" to non-default-os python.
2. set up aliases to alternative python versions.
In other words, replace e.g. this:
# added by Miniconda3 4.0.5 installer
export PATH="/Users/PatrickT/miniconda3/bin:$PATH"
with this:
## create alias to miniconda/anaconda
## to make conda command accessible, first run: condainit
alias condainit='export PATH="/Users/PatrickT/miniconda3/bin:$PATH"'
## create alias to other python versions
alias pyconda='/Users/PatrickT/miniconda3/bin/python'
alias python3='/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}'
## After installing pyenv with homebrew and run $ brew info pyenv
## set the following, according to the "caveat instructions":
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
Source the .bash_profile:
$ source ~/.bash_profile
To access conda commands run this in the terminal:
$ condainit
$ conda info -e
To access the Python3 provided by conda, type:
$ pyconda
To access the Python3 installed via the dmg, type:
$ python3
To access the default OS-provided python (currently Python 2.7), type:
$ python
Among other sources, the following was particularly useful: Using two different Python Distributions
I'm on a Windows machine, so unfortunately I can't use RVM, which would make this super easy.
I previously downloaded Rails and Ruby on a new Windows machine. Rails 4.0.3 and Ruby 1.9.3. For some reason, the package I installed didn't install the new version of ruby. So I just went to http://rubyinstaller.org/downloads/ and downloaded Ruby 2.0.0. If I browse to my Apps to access the Start Command Prompt with Ruby, the version is 2.0.0 (ruby -v). But I use Git Bash, http://git-scm.com/downloads, as my Command Line. Right now, the current ruby version is still 1.9.3 in my Git Bash window. How do I update it to use the newly downloaded Ruby 2.0.0???
Thanks for the help.
Issuing
$ which ruby
will tell you which of the two ruby executables GIT Bash wants to use.
For situations where it is necessary to have two versions of Ruby, it's possible to select one or other for general use using the PATH environment variable.
The order of paths in the Bash $PATH environment variable is important - if the path for your ruby 1.9.3 executable appears before the path for your ruby 2.0.0 executable, then the interpreter will use the 1.9.3. So, for example;
Ruby 1.9.3 is in /c/Software/Ruby/1.9.3/ruby.exe
Ruby 2.0.0 is in /c/Program Files/Ruby/2.0.0/ruby.exe
And your PATH variable is as follows;
$ echo $PATH
/c/GIT/bin:.:/c/Software/Ruby/1.9.3/:/c/Program Files/Ruby/2.0.0/
Then you would need to re-order your PATH variable so that the 2.0.0 path comes before the 1.9.3 path. Find your .bashrc file (by default in your home directory) and examine any PATH definitions, e.g.;
PATH=$PATH:/c/Program Files/Ruby/2.0.0/
And modify so that your 2.0.0 path has precedence
PATH=/c/Program Files/Ruby/2.0.0/:$PATH
You can issue this command on the command line also, making sure to do
$ export $PATH
once you've made your changes. Otherwise you'll need to source .bashrc or start a new shell. GIT Bash should then pick up the correct executable.
An alternative is to create aliases or symbolic links for each executable which specifies their version, such that typing ;
$ ruby193
Executes the 1.9.3 ruby and
$ ruby200
executes the 2.0.0 version.
Aliasing is as follows;
$ alias ruby193=/c/Software/Ruby/1.9.3/ruby.exe
Linking is as follows;
$ ln -s /c/Software/Ruby/1.9.3/ruby.exe /c/GIT/bin/ruby193
Aliases you use frequently should be put in .bashrc .
I've configured a new server on Ubuntu 12.04 and I started to use RVM.
I've installed RVM under my user (as myself, not as root with sudo) by following the Ryan Bigg's guide, with no previous system-wide installed Ruby. So, I didn't have any Ruby under /usr/bin. My first task then was to replace the shebang line of all my CGI scripts, from
!#/usr/bin/ruby
to
!#/usr/bin/env ruby
However my scripts didn't run under Apache. In the terminal I could run them (by typing ./index.cgi, for example), but not over a browser. A relevant note: in both the user is the same, i.e., the Apache user is the same as the one logged on terminal. Through php tests, I've checked the RVM enviroment (last lines of .bashrc) was not loaded under Apache.
I saw this tip for running CGI scripts with RVM, which suggests to put the complete path of specific version of Ruby in the shebang line. That can be useful if you have scripts which run on different versions of Ruby. But that solution doesn't work for me, because my scripts must run on different machines, with different users and different paths.
The solution which works for me is to put a symlink of the desired Ruby version under /usr/bin:
sudo ln -s /home/apache_user/.rvm/rubies/ruby-1.8.7-p370/bin/ruby /usr/bin/ruby
But I want to know if there's a better solution, because I guess that rvm --default use is better than sudo ln -s.
I am thinking about:
loading the RVM Environment on startup (but I don't know how to achieve that);
loading the RVM Environment for each web request (which can degrade performance, and I don't know how to configure Apache to do that);
maybe the RVM Environment is loaded and all I must do is to guess the name of relevant variables to pass with PassEnv directive. But I doubt that. (Why Apache would run the .bashrc instead of another shell like csh or ksh?)
you can source the ruby environment, I'm not sure if it's enough to source it in $HOME for apache or if you need to modify /etc/init.d/apache2, but the line is:
source /path/to/rvm/environments/<name>
where for <name> you can either use full ruby name or an alias name
You can create aliases with:
rvm alias create veve 1.9.3-p125#my-project
which for RVM installed in /home/app/.rvm will allow you to use:
source /home/app/.rvm/environments/veve
in .bashrc or /etc/init.d/apache2 (just near top, bellow shebang).
you could always do
sudo ln -s /usr/local/rvm/rubies/default/bin/ruby /usr/bin/ruby
That will link the default version of the rvm-managed Ruby to /usr/bin/ruby and you will never have to do anything. set it and forget it.
On arch linux, after install virtualenvwrapper system-wide, via sudo pip2 install virtualenvwrapper and adding this in my user's .bash_profile,
export WORKON_HOME=/home/myuser/.virtualenvs
export PROJECT_HOME=/home/myuser/work
source /usr/bin/virtualenvwrapper.sh
An error shows up whenever I launch a new shell window:-
which: no python in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl)
-bash: : command not found
virtualenvwrapper.sh: There was a problem running the initialization hooks. If Python could not import the module virtualenvwrapper.hook_loader, check that virtualenv has been installed for VIRTUALENVWRAPPER_PYTHON= and that PATH is set properly.
This can be traced to line 50 in the virtualenvwrapper.sh script:-
47 # Locate the global Python where virtualenvwrapper is installed.
48 if [ "$VIRTUALENVWRAPPER_PYTHON" = "" ]
49 then
50 VIRTUALENVWRAPPER_PYTHON="$(\which python)"
51 fi
And is a result of the conflict with arch linux's convention of using python2 for python 2.7 installation.
If I modify line 50 to which python2, everything works perfectly and I will not see the error message whenever I launch a new shell.
What is the appropriate way of resolving this problem? Do I write an explicit check that the current OS is arch linux and introduce an if-else condition to use which python2 in virtualenvwrapper.sh and send the patch to the virtualenvwrapper author? Or is there something I can do with my configuration in my arch linux machine?
Virtualenvwrapper has variables VIRTUALENVWRAPPER_PYTHON and VIRTUALENVWRAPPER_VIRTUALENV which point to your python and virtualenv executables. So, in your .bash_profile you can write something like:
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python2
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/bin/virtualenv2
source /usr/bin/virtualenvwrapper.sh
To answer this arch-specific python quirk (the convention of using python2), I specifically create a soft link like this:-
ln -s /usr/bin/python2 /usr/local/bin/python
Since /usr/local/bin precedes /usr/bin in the bash system PATH environment variable, when I type python, or when the virtualenvwrapper.sh script refers to which python in line 50, we will no longer run into the above mentioned virtualenvwrapper conflict and everything works as expected.
The disadvantage of doing this is that it might mess up the "python 3" (being considered as the default python command) conventions arch linux is designed for. So care has to be taken that I do not use python 3 related libraries or package installations relating to python 3 in my target box.
I found there is no need to edit the /usr/bin/virtualenvwrapper.sh script or create a new symbolic link. I was just missing the virtualenvwrapper module for python2. I installed it like the following:
pip2 install virtualenvwrapper
and keeped the exports so the magic is done.
After trying to install ruby19 on my machine (PPC, Mac OSX 10.5.7) using the following commandline
sudo port install ruby19
the version of ruby didn't change
ruby -v => ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
I assume that i have two versions of it installed on my mac, but how do i use the latest one now?
By default, the Ruby 1.9 port in MacPorts installs the Ruby binary in /opt/local/bin/ruby1.9. It appends a 1.9 to avoid stomping on Ruby 1.8.7 libraries and gems, since not all gems are compatible with 1.9 yet. So you have to launch Ruby 1.9 with ruby1.9 (and irb1.9, etc.)
If you don't want to have to do this, you have two options:
Alias ruby to ruby1.9 in your shell config file.
Install the Ruby 1.9 port with the +nosuffix variant. Be warned, however, that if you have installed Ruby 1.8 via MacPorts, installing Ruby 1.9 via MacPorts without the 1.9 suffix may cause conflicts (with gems, etc.).
To use a specific ruby version if you have two versions installed you can either specify an absolute path to the one you want. E.g. /your/path/to/ruby Or you can change your PATH setting in your .profile
you can type
which ruby
to see the path to the ruby executable that is used at the moment.
using
echo $PATH
You can see the current PATH setting. You have to prepend the path to your new ruby binary to the PATH so that it will be found before the other one.
As ayaz already mentions, the default location of your macports stuff is in /opt/local. If you add /opt/local/bin in front of your path it should be fine. (Make sure to start a new terminal window after the change - they will not be picked up in your current session unless you explicitely 'source' the .profile file again)
One note of caution: after prepending /opt/local/bin to your path the shell will always prefer binaries in there to binaries found later, this can be an issue if you depend on specific versions in /bin, /sbin or /usr/sbin -- depending on your situation this means that you should not do it (if your computer is processing sensitive data and/or in a bank or something) or just have to remember that it could be an issue (if your computer is a normal development machine).
See http://www.tech-recipes.com/rx/2621/os_x_change_path_environment_variable/ if you need some more hints on how to set your PATH on osx.
Just a quick clarification about MacPorts. Ayaz is right that, by default, MacPorts will install things in /opt/local. (This makes it easy to globally uninstall later, if you want, and it keeps MacPorts packages out of the way of OS X packages.)
When you install MacPorts, it will normally edit your $PATH (and your $MANPATH) for you by updating your user's .profile (creating it, if it doesn't already exist).
As a precaution, the installer will create a backup of the original .profile in case you want to roll back the changes (or if you completely uninstall MacPorts later). Here's an example from a random machine at work.
admin ~ $ ls .profile*
.profile .profile.macports-saved_2009-08-03_at_14:55:56
If you look in .profile you should see something like this:
##
# Your previous /Users/admin/.profile file was backed up as /Users/admin/.profile.macports-saved_2009-08-03_at_14:55:56
##
# MacPorts Installer addition on 2009-08-03_at_14:55:56: adding an appropriate PATH variable for use with MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.
# MacPorts Installer addition on 2009-08-03_at_14:55:56: adding an appropriate MANPATH variable for use with MacPorts.
export MANPATH=/opt/local/share/man:$MANPATH
# Finished adapting your MANPATH environment variable for use with MacPorts.
If your $PATH hasn't been updated, you should adjust it, since otherwise, you will have trouble using the port tool and the software you install via MacPorts.
I am inclined to think that macports usually keeps all of its stuff inside the /opt/local directory. I am using Leopard, and I have it inside that directory. You may want to look in there, particularly inside /opt/local/bin, to find the ruby binary you are looking for.