chruby is overriding the environment variables after chgems sets them about chgems HOT 14 CLOSED

Simply loading chruby.sh shouldn't change any of the variables (besides RUBIES). Is there anything else in your bash config?

from chgems.

Perhaps it is the auto-switching that is doing it then. Here is the entire contents of my .bashrc file.

source /usr/local/share/chruby/chruby.sh
source /usr/local/share/chruby/auto.sh

from chgems.

Bingo. Yeah, unfortunately the auto-switching activates and will override GEM_HOME. -norc would work for bash, but zsh requires -f -d. Also, chgems path/to/project would not cause auto.sh to auto-switch to the ruby specified by the project's .ruby-version file. I do really need to think of a better to handle this.

from chgems.

I had the same problem as @sailorsteve.
I left my .bashrc like this:

source /usr/local/share/chruby/chruby.sh

and moved these to my .profile:

source /usr/local/share/chruby/auto.sh
chruby 1.9.3

Now everything mostly works as long as I move to a project like this:

cd project && chgems

The remaining problems:

• auto.sh isn't loaded in the new shell, so if I stray from one project to another, I need to remember to run chruby/chgems again.
• It would be nice to just chgems project and have the correct ruby set up, as well as the correct gems.

from chgems.

why not simply add the chruby(auto) functionality to chgems or add the chgems functionality to auto.sh from chruby?

from chgems.

So as I understand it, the problem is that the chruby auto.sh gets re-triggered within the subshell that chgems creates, overwriting part of the environment. Would the following patch work?

---
 share/chruby/auto.sh | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/share/chruby/auto.sh b/share/chruby/auto.sh
index f8a0a85..a0f5e08 100644
--- a/share/chruby/auto.sh
+++ b/share/chruby/auto.sh
@@ -1,5 +1,3 @@
-unset RUBY_AUTO_VERSION
-
 function chruby_auto() {
        local dir="$PWD" version

@@ -7,7 +5,7 @@ function chruby_auto() {
                if { read -r version <"$dir/.ruby-version"; } 2>/dev/null || [[ -n "$version" ]]; then
                        if [[ "$version" == "$RUBY_AUTO_VERSION" ]]; then return
                        else
-                               RUBY_AUTO_VERSION="$version"
+                               export RUBY_AUTO_VERSION="$version"
                                chruby "$version"
                                return $?
                        fi
--

Edit: sorry, posted this half-drafted - currently trying to get the tests running to see if they pass.

from chgems.

Okay, test_chruby_auto_loaded_twice fails with that patch, as RUBY_AUTO_VERSION is no longer unset as asserted. The assertion was added in this commit, which sought to make sure chruby_auto did get re-run in subshells so that its own PATH modifications didn't get clobbered by other things in a user's .bashrc or .zshrc.

So the solution to that problem is fundamentally at odds with this one, where we do have something that's modifying the environment before auto.sh gets invoked, in a way we'd like preserved.

In my environment I've fixed this by creating a wrapper script for chgems that sets an environment variable that I can test for in my .bashrc and prevent auto.sh from being invoked if necessary:

if [[ -f "/usr/local/share/chruby/chruby.sh" ]]; then
  source "/usr/local/share/chruby/chruby.sh"
  if [[ ! -n "$CHGEMS_ACTIVE" ]]; then
    source /usr/local/share/chruby/auto.sh
  fi
fi

Which seems to work so far, although I'm sure there'll be some problem with it I haven't thought of.

from chgems.

Having successfully bested #12, I encountered this. :( Not sure what to do about it; it's not as simple as "Apple shipped a broken /etc/zshenv".

from chgems.

A workaround to this issue is to only load chruby/auto.sh in ~/.bash_profile or ~/.zprofile. This will load chruby's auto-switching only for login shells, and not sub-shells. This is not a perfect workaround, since some users want chruby's auto-switching to trigger for both login, interactive and even non-interactive sub-shells.

@urbanautomaton I would prefer to keep chgems and chruby independent of each other.

@sailorsteve forcing the shell to not load any configuration is one option. Although, it also suppresses any additional user configuration from being loaded as well.

from chgems.

Would this be relate to why I'm having issues with chgems A) setting my gempath, B) getting the version wrong?

from chgems.

Closing this since it's been thoroughly discussed. Would be more interested in undoing this commit postmodern/chruby@5d35785 which fixed a tmux issue but also broke chgems.

from chgems.

FYI I've started writing an in-shell function called gem_path for manipulating $GEM_PATH/$PATH. I will probably deprecate chgems in favor of gem_path once it reaches maturity.

from chgems.

Is there a way of detecting that it's a chgems subshell? - or if not currently, could we set something?

I currently load chruby system-wide in /etc/profile.d/chruby.sh (as put there by my chef recipes) so it would be good to have something in chruby.sh which sources /usr/local/share/chruby/chruby.sh and then only sources /usr/local/share/chruby/auto.sh if it's not a subshell, rather than using the .bash_profile / .zprofile above.

Thanks,

Ian

from chgems.

@ichilton hmm I suppose you could add a check for what type of shell the config is being loaded in? Not sure what the best way to do that would be?

from chgems.