enter image description here
how to change the value of these variables I tried by setting env variables in .profile and .bashsrc file .but nothing worked. I have uninstalled the ruby 2.7.0 also but this env variable still shows some entries with ruby 2.7.0.
I just want to update them with ruby 2.7.1.
Related
After upgrading to Yosemite my ruby dev environment was not working well so I thought I would take the opportunity to switch to chruby from rbenv.
It's all gone pretty well after installing and I can switch between rubies easily, but I cannot set a default Ruby.
If I add the line chruby ruby-2.1.3 to my ~/.zprofile file then open a new terminal window I get the following error message;
/Users/brad/.zprofile:1: command not found: chruby
I have added source /usr/local/share/chruby/chruby.sh to my ~/.zshrc file as described in the configuration section for chruby. I'm not sure what else to do to get this working - I'm no expert at finding my way around shell config settings. Any clever ideas?
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 installed bash-it recently and I noticed it broken RVM. When I enter a project directory, the ruby version is not changed (not matter if I use .rvmrc or .ruby-version). However, when I enter a project directory and then open a new tab/window in terminal, ruby version is changed. I tested it in Konsole and Gnome Terminal. I keep bash-it configuration in .bash_profile and I'm loading it in the end of .bashrc. Any ideas for the reason for such a strange behaviour?
EDIT: I tried to start bash as a login shell, but it doesn't work.
I just upgraded my Postgres.app to latest version (9.2.4.1) am now unable to start my Rails app using Foreman or Rails server.
/Users/memoht/Sites/myapp/.gem/ruby/1.9.3/gems/pg-0.15.1/lib/pg.rb:4:in `require': dlopen(/Users/memoht/Sites/myapp/.gem/ruby/1.9.3/gems/pg-0.15.1/lib/pg_ext.bundle, 9): Library not loaded: #executable_path/../lib/libssl.1.0.0.dylib (LoadError)
Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib
Reason: image not found - /Users/memoht/Sites/myapp/.gem/ruby/1.9.3/gems/pg-0.15.1/lib/pg_ext.bundle
Looked through Postgres.app documentation
Upgrade from 9.2.2.0 to 9.2.4.1 isn't a new minor release so shouldn't involve pg_upgrade
.bashrc has correct setting for PATH PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
Uninstalled, and reinstalled PG gem.
Made the mistake of thinking I needed to install PostGIS via homebrew, but that automatically installed Postgres via Brew plus a slew of other dependencies.
If I swap out the Postgres.app version back down to 9.2.2.0 everything works again. Since Postgres.app is a drag and drop install, why has upgrading from 9.2.2.0 to 9.2.4.1 caused this?
I found a solution that works for me and requires minimal hacking/configuring. You only need to do this once and it will work for every bundle install. Add the following to your .bash_profile, .bash_rc, or equivalent:
export DYLD_FALLBACK_LIBRARY_PATH=/Applications/Postgres.app/Contents/MacOS/lib:$DYLD_LIBRARY_PATH
(Assuming you installed Postgres.app in the default location). Then restart your terminal session and try again.
Exporting to DYLD_LIBRARY_PATH directly can cause serious problems with other apps that depend on it, but using the fallback path avoids these problems.
See also:
Error requiring pg under rvm with postgres.app
https://github.com/PostgresApp/PostgresApp/issues/109#issuecomment-18387546
EDIT: It seems that setting DYLD_FALLBACK_LIBRARY_PATH causes an error when you try to run psql. To fix this, you can add the following two lines to your .bash_profile:
alias psql="(. ~/.bash_profile; unset DYLD_FALLBACK_LIBRARY_PATH; psql)";
This is assuming that you're using bash and that your .bash_profile is located in your home directory. If that's not the case (or if you're using a .bashrc or other environment setup instead of .bash_profile) change the ~/.bash_profile part of the command to the path to your environment setup script.
The aliased commands basically start a subshell which does not effect your current bash environment. So when it unsets the DYLD_FALLBACK_LIBRARY_PATH variable, it's only temporary. After you exit psql the environment variable will be set again so that rails functions properly.
It's likely your pg gem in your app was built against the old libraries. Try rebuilding it against the new Postgres.app:
$ gem uninstall pg
[...]
$ bundle install
[...]
"installing pg" (or something..)
I am trying to get informations about the installed versions of ruby inside RVM and the associated gemsets and gems.
My first idea was to use a system call to rvm list to get the installed Rubies and rvm use #{ruby_version} && rvm gemset list for every Ruby. But there is an issue with that. It seems that rvm use #{ruby_version} is executed and confirmed by RVM (output Using #{path_to_ruby), but the gemsets listed are the one from the Ruby version that runs the script.
Is there any way to communicate with RVM from a Rubyscript via CLI or an API?
I'll take a stab at this - I think your problem is that rvm works mostly by mucking around with your environmental variables to point your shell to the different gemsets and ruby versions.
But when you run rvm use in a subshell the changes of the env variables are not propagated up to the parent shell.
Without having looked into this too much yet, my initial idea would for you to run the rvm use thing + then in that same subshell session run something that lists the contents of all these updated env vars (see here for which ones you need to look at: http://beginrescueend.com/rvm/info/ )...then in your ruby script you need to set the environment to match the environment in your subshell.
In shellspeak what you usually do in a case like this is "source" the script instead of executing it. I.e. source "the_script_that_sets_environment_variables". But when you are in a ruby script and use backticks to run stuff in a subshell you can't propagate the environment back up to the parent without doing it manually.
Another solution might be to take a look at the RVM Ruby API. I didn't find much documentation on it yet, but it might also do the trick for your case:
http://www.rubyflow.com/items/4285