RVM Install and Dotfiles

[kmowery]

After installing RVM earlier today using the rvm-install script, I found that my bash environment had mysteriously gone missing. The culprit?

rvm-install created .bash_login and modified .bashrc, while my shell configuration lives in .profile (and .bashrc is a pointer to .profile). Upon creating a new shell, .bash_login shadows .profile and my configuration silently disappears.

rvm-install should, instead, check for the existence of .profile, .bash_login, and .bash_profile and, if one is found, modify the one with highest bash priority. Only if none exist should rvm-install create a new file.

Lastly (and this is a philosophical issue and not part of the bug), rvm-install should not touch my dotfiles under any circumstances. Let the user do that. You don't know what you might be breaking or how the environment is configured. At the very least, add a switch to rvm-install that turns off dotfile modification and provide appropriate documentation for the user to configure their shell environment hemselves.

[mpapis]

please read this: https://rvm.beginrescueend.com/support/faq/#shell_login

rvm will not add itself to your profile files if it finds loading itself in one of them, you can force rvm to re-add itself with rvm get head --auto.

just move the rvm sourcing line from .bash_profile to .profile if this is really your desire.

current behavior is the best thing we can do to conform to the mentioned doc, if you have better algorithm for this please open a pull request with your proposal - I will have a look on it.

[mpapis]

as for the switch, tell me you read all the text in here (before installing) : https://rvm.beginrescueend.com/rvm/install/ - I will add the switch then.

[richo]

Probably worth noting that the heuristic for loading itself could probably do with updating.

I installed RVM on a machine that has had my dotfile environment for a long time and was surprised to find it had updated both my .zshrc and .bashrc.

[mpapis]

it's a new thing with PATH in .*rc files - but I can not think about a way this could break anything

[mpapis]

btw. @richoH what do you think about adding sourcing default in .*rc - I did not wanted to do it without any surveys asking out loud, this is more inasive then adding rvm to PATH

[richo]

I'm just reading through functions/installer now to see why it didn't see my sourcing line.... aaaand now I see why.

# RVM Hax.
for _rvm in "$HOME/.rvm/scripts/rvm" "/usr/local/rvm/scripts/rvm"; do
    if [[ -s "$_rvm" ]]; then
        # Do rvm initialisy stuff
        export have_rvm=true
        source "$_rvm"
        function cdgems() {
            cd "$GEM_HOME"
        }
        break
    fi
done

A kludge I implemented ages ago to have the same .profile work on multiuser and single user installs. WRT to sourcing as opposed to adding to PATH, I'm not against the idea per se (although some documentation is important) however I was profiling my environment a while ago and lazy loading rvm (not actually commencing loading until the first time it's invoked) could be a feasible option, there would need to be minimal checks for default ruby etc.

I'm making myself a note to file a meta-issue tonight with my thoughts on the matter :)

[richo]

I did just have a thought, probably best to invoke a branch new login shell and ask it to output PATH and some rvm internal and inspect that, rather than grepping it's config.

That way even if the user does something insane and counterintuitive (like what I ended up doing) you can still work out quite reliably if they're already setup to load RVM.

[mpapis]

that could work as a check, it would allow checking zsh/bash interactive/login behaviors ... but anyways for custom configs --auto will not work as expected

[richo]

I'm talking specifically about the same usecase that @kmowery reported- being alarmed that rvm touched my dotfiles when it didn't need to.

Personally I favour the message saying "This is the line that you need to make sure is run at init time, unless you know better" at the end of installation, but I'm willing to bend and see the merit in installing automatically, but I think the "I'm not sure" case should default to not touching anything.

[mpapis]

ok scheduling for 1.10.4, @richoH solution with subshell could work, I see few flaws - like when run from rvm get head but overall it's not that bad idea worth investigating. As for the automatic updating - rvm was already doing it for at least half year, it just got updated and perfected to conform to this doc: https://rvm.beginrescueend.com/support/faq/#shell_login - which I take as a base for work with any RC files.

[richo]

While we're on the topic, I just ran rvm get head to make sure my rvm new about 1.9.3-p125, and it added the lines to .zshrc and .bashrc /again/

At the end of the day, Id' say it's a safe assumption that the user has rvm working when they invoke rvm get head.

I'm happy to take this on board, then get your feedback when I've got a patch.

[kmowery]

I read the document at https://rvm.beginrescueend.com/support/faq/#shell_login . I believe it is mistaken: in case 2, if .bash_profile is not found, bash will look for and source ~/.profile. If .profile exists and .bash_profile does not, I believe the correct approach is to modify .profile or .bash_login, instead of creating .bash_profile (and possibly disabling important things in .profile). This would prevent breakage in the case of "nonperfect" environment setup. (I don't have a pull request, though.)

As for the installation instructions, before installing, I read almost all of it, as well as the installation script at https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer in order to understand its behavior regarding dotfiles. As I understood it, that script doesn't make the changes, but rather executes ./scripts/install from the downloaded tarball, and so its behavior is unclear until run.

(As a side note, why is there a "Load RVM into your shell sessions as a function" step in the longer instructions when the script in step 1 does it as per the Quick Install? The reader might assume that parts of that doc are out of date.)

[mpapis]

I can not agree with you on the source ~/.profile it will be read by BASH when it starts and not source ~/.bash_profile found. Using .profile instead of .bash_profile is a bad practice, the catch is that it's also read by graphical environment and putting there stuff like RVM will make you curse , it will load RVM for the whole graphical session and things like changing default ruby will not work unless you restart it.

As for the installation page it's a bit deprecated (as other parts of the site are also) but as almost nobody goes bellow the quick part it has lower prio then implementing automated behavior that will make it just work from start.

We would use some help from contributors for updating the rvm-site as we do not use all the flows all the time and can't say when the docs get outdated, even telling us that something is outdated would be great, any pull requests are also very welcome.

[kmowery]

I understand your reasoning about .bash_profile. However, for people who either aren't following best practices or simply are sharing config between individual shells and login, the rvm-install script breaks their shell environment. I propose:

1. If .bash_profile exists, add the rvm-specific code to it.

2. If .bash_profile does not exist and either .profile or .bash_login exist, create a new `.bash_profile like so:

   source ~/.profile (or .bash_login, as appropriate)
   [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session as a function

3. If none of these files exist, create .bash_profile with the rvm-specific code.

This approach shouldn't break the user's existing dotfile setup, while maintaining .bash_profile semantics for rvm.

As for the installation page, I understand that documentation can sometimes slip. However, you asked if I had read the entire page before installing (which I had).

[dyfrgi]

From discussion on IRC with mpapis:
In addition to the detection layer, an override would be useful. That way, if the detection goes awry, a user can specify "no really, it's set up the way I want it to be, I know what I'm doing, don't edit my dotfiles". Such an override must be persistent, not just a commandline flag, so that you don't need to remember it every time, though also having the commandline flag would be nice. --no-auto seems like the obvious name, if so.

I suggested an environment variable, mpapis suggested a flag in ~/.rvmrc. Either seems like it'd work fine for users who have this problem.

I also think that actually creating the configuration file is probably the wrong approach, unless the user has no shell configuration files at all. That's what created the specific problem with shadowing of one file by the existence of another.

[richo]

Sorry guys. Ice been really slack with this. Hopefully I'll put something together in the next few days- every rvm get head breaking my dotfiles is a good reminder

On 02/03/2012, at 7:27 AM, Michael Leuchtenburgreply@reply.github.com wrote:

From discussion on IRC with mpapis:
In addition to the detection layer, an override would be useful. That way, if the detection goes awry, a user can specify "no really, it's set up the way I want it to be, I know what I'm doing, don't edit my dotfiles". Such an override must be persistent, not just a commandline flag, so that you don't need to remember it every time, though also having the commandline flag would be nice. --no-auto seems like the obvious name, if so.

I suggested an environment variable, mpapis suggested a flag in ~/.rvmrc. Either seems like it'd work fine for users who have this problem.

I also think that actually creating the configuration file is probably the wrong approach, unless the user has no shell configuration files at all. That's what created the specific problem with shadowing of one file by the existence of another.

---

Reply to this email directly or view it on GitHub:
#774 (comment)

[richo]

I'm thinking the mere existnce of ~/.rvmrc (even if empty) is probably the best heuristic?

I also think a lot of the code around there is either extraneous or really needs documentation.

[mpapis]

additional thing to be included from #805 - generate files for existing shells only.

[gjorgensen]

Had the same issue with it breaking my dotfile setup and rendering alias etc. non-functional.

[mpapis]

rescheduling for 2.0 (unless someone else want to step up and implement it)

@gjorgensen RVM displays information which files are modified during installation/update, if you are using different files just move the lines around and it will be working as you prefer it to be, to prevent RVM from updating this files again just leave the lines commented and RVM will skip those files.

[avakarev]

One more case about that. I keep my rvm related staff in ~/.bash/exports and I have both ~/.bashrc and ~/.zshrc
Actually I use only zsh these days, but both of rc is in my dotfiles repo and symlinked to ~/.*rc
Despite of ~/.bash/exports sourced in both rc and ~/.rvm/bin already included in PATH, "rvm get stable" ALWAYS write to both ~/.zshrc and ~/.bashrc (adds ~/.rvm/bin to PATH)

Is it related to this issue?

I believe any files outside of ~/.rvm shouldn't be touched on updating.

[mpapis]

@avakarev yes it's related and @richoH proposed solution should detect it, but as there is easy workaround i have to reschedule it to RVM 2.0.

The workaround is to just comment out (#) the new lines in your RC files, RVM 1.x will take it as already properly setup RVM and will not add them again.

[richo]

I've been hacking around my idea and the closest thing I've got to a PoC is so fragile it'd be impossible to roll it out in production.

I've been forced to backpedal, I'm thinking that the original idea @mpapis had to have a rvm_configured flag in ~/.rvmrc or somesuch is the way forward.

It should probably be versioned rather than boolean though so if the rvm load process changes we can warn existing users that they'll need to update their config.

[mpapis]

@richoH we can make it easily versioned by just checking >0 instead of ==1, but as I already mentioned, this is not urgent for me as an easy workaround exists which I'm using too. I will happily merge any pull request - just will not do it myself in rvm 1.x.

[nhusher]

This caused me an hour of development pain this morning: I installed rvm because it was recommended to me by a collaborator to solve a particular problem I was having. And then an hour later my environment blew up.

It took me a while to figure out that it was because I had restarted Terminal and reloaded my environment configs, and a while longer to figure out that rvm was the culprit. I scooped the following files out of my home directory that did not exist previously: .bashrc, .bash_login, .zshrc, and .zlogin. I use .profile and bash.

[mikl]

For a random sysadmin that works with all sorts of tools, this is a pretty annoying change. I've used rvm when setting up apps for clients before, but when I installed and ran it as usual today, it took a giant dump all over my homedir, breaking other ruby tools I was using.

It's inconceivable to me why you consider this to be a reasonable thing to do without as much as prompting. I know this is an attempt to be helpful to new users, but these changes breaks stuff if you already had a standard, non-rvm environment set up, and it makes the shell start up a lot slower, which is kinda annoying when I don't use rvm 99.9% of the time.

Not acceptable.

[ghost]

Agreed, this is the largest issue I have with rvm.

Now, if there was an option to prevent it from modifying my config files and instead suggest me the modifications (kinda like phusion passenger guys do when installing apache module), that would be very acceptable workaround.

Or at least option to prevent it from modifying the config files, that would be almost acceptable :)

[mpapis]

@olek-modcloth just comment out the changes and installer will not touch those files again - this is the current workaround, I'm happy to accept any pull request changing this to optional with some kind of switch in ~/.rvmrc file

[mikl]

@olek-modcloth I ended up setting up a separate user account for working with RVM. Since my dotfiles are version-controlled, having all this commented-out RVM junk in them was aggravating.

[NightMachinery]

It would be a good idea to mention the option --ignore-dotfiles in the getting started guide. In general, just asking the user is better. Scripted usage will specify a flag to either enablle or disable the behavior, but just running curl -sSL https://get.rvm.io | bash -s stable --rails should simply ask the user if they want their dotfiles updated.