chruby problem with tmux about chruby

[postmodern]

Looking at this similar rbenv issue, did you restart tmux after configuring chruby?

[postmodern]

Also ensure that tmux is creating shells that are login/interactive (-l option).

[pentikos]

Yes, I did restart tmux after configuring it. Starting tmux with the -l flag does not help.

[postmodern]

Also is this happening in one tmux window, or between multiple ones?

[pentikos]

It happens in all tmux windows. I noticed that all env variables are set by chruby, except the PATH.

[Gibheer]

Working here with the following in my .profile

source profile.d/chruby
RUBIES=(/home/gibheer/src/rubinius)
chruby rubinius

This is on an archlinux and freebsd with tmux and zsh.

[havenwood]

Reproduced same issue as donpinkster with OS X, tmux and zsh. Sourcing chruby.sh and .zshrc from within tmux didn't fix.

[havenwood]

Switch .zshrc sourcing of chruby to latest from readme, and now tmux works in first screen and new screens.

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

[pentikos]

I have been digging around and found out the problem was on my side. Somewhere in my config I had the following:
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin
Changing that to
export PATH=$PATH:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin
fixed the problem. Stupid mistake 😄

[postmodern]

Ah ha!

[yorickpeterse]

For those experiencing similar issues: I managed to solve this issue by running chruby_reset before specifying the default version in my .bashrc file.

[postmodern]

@yorickpeterse Interesting. chruby_use calls chruby_reset if a Ruby has already been selected.

[yorickpeterse]

Interesting bit: it works fine on my Xubuntu installation (without calling chruby_reset) yet on my Arch Linux installation it is required. This leads me to believe it might be an issue with recent versions of Tmux as my Xubuntu installation uses Tmux 1.6 while my Arch Linux installation uses 1.7.

[Gibheer]

@yorickpeterse are you sure you have nothing else in your .profile or .zshrc? I'm using tmux 1.7 and zsh and don't experience any problems. Maybe something from /etc/profile.d/ does an override for you?

[postmodern]

@yorickpeterse @Gibheer another possibility is Arch modified /etc/zshrc or /etc/zprofile. I can confirm that Fedora did modify /etc/zshrc.

[yorickpeterse]

Considering I'm running Bash and not Zsh, wouldn't that mean those files are never loaded to begin with?

[postmodern]

@yorickpeterse ah, than you would want to check /etc/bashrc, /etc/profile and ~/.bashrc.

[chrismytton]

@donpinkster @postmodern @yorickpeterse I've just been investigating this issue on OS X with tmux 1.7 and chruby 0.2.5.

I also reset my PATH in ~/.zshenv (/etc/paths on OS X puts /usr/local at the end, which I'm not a fan of). It seems that when I start a new terminal window, chruby sets the default ruby correctly, but when a new tmux session is started $RUBY_ROOT is already in the environment, so the short circuit check in chruby_use passes and the chruby_reset is never called.

Adding a call to chruby_reset before setting the default version in ~/.zshenv does indeed solve the problem. But it seems to me that calling chruby_use should always call chruby_reset if $RUBY_ROOT is set to ensure a clean environment, and just remove the short circuit altogether.

What do you think?

[chrismytton]

I can confirm that removing the short circuit check makes chruby work out of the box with tmux using the README instructions.

[postmodern]

As a workaround, should we call chruby_reset when loading share/chruby/chruby.sh?

[chrismytton]

Yea I like that, seems like a good solution. Just made the change locally and it works as expected.

Thanks for your work @postmodern, chruby is an awesome piece of software.

[postmodern]

Changed in master. Please test master to confirm the fix.

[chrismytton]

Confirmed working. 👍

[postmodern]

@hecticjeff Upon further thought, you should not be overriding your PATH, but instead use shell String manipulating to remove /usr/local from PATH, and insert it before /usr. This would preserve chruby's modifications to PATH.

Also, I realized that by calling chruby_reset, it makes it impossible to change Rubies and then spawn a sub-shell that uses the same Ruby.

[postmodern]

@hecticjeff but you do make a convincing argument for the removal of the short circuit. PATH or GEM_PATH could be modified by another program, which might require the user to reset the environment by calling chruby again.

[chrismytton]

@postmodern Approved! ❤️

[yorickpeterse]

👍 Nice work

[postmodern]

All new features have been merged into the 0.3.0 branch. Feels like 0.3.0 isn't far off, so maybe this fix will be released in 0.3.0 instead of 0.2.6.