GitBash outside of RStudio does not see the default user library, whereas GitBash inside RStudio does

On Windows 10, version 2004, I have today installed GitBash, R & RStudio. When I ask for the library paths in GitBash outside of RStudio (opened by clicking on the icon from the Windows start menu), I cannot see the default user library. Specifically, in GitBash when I type:

Rscript -e ".libPaths()"

I get:

[1] "C:/Program Files/R/R-4.0.2/library"

However, when I type the same thing (Rscript -e ".libPaths()") inside RStudio, I get both library paths:

[1] "C:/Users/tiffany.timbers/Documents/R/win-library/4.0"
[2] "C:/Program Files/R/R-4.0.2/library"

This is a reproducible "feature" that I have observed on my machine, and across many of my students' Windows machines in my teaching. I would like to know what causes this difference. Where is GitBash inside RStudio getting the information about the library paths from?

I remember spending a long time trying to figure this out before :slight_smile:

The problem is that Git Bash has a special HOME environment variable set that changes how R finds the default user library. On Windows, R determines the default user library path using something like this:

  • The R_LIBS_USER environment variable, if set
  • Otherwise if the R_USER environment variable is set, $R_USER/R/win-library/VERSION
  • Otherwise if the HOME environment variable is set, $HOME/R/win-library/VERSION
  • Otherwise, in the user's Documents folder (usually C:\Users\username\Documents\R\win-library\VERSION)

In most cases, none of these environment variables will be set on Windows, so R will use the My Documents folder by default.

However, Git Bash has a HOME environment variable set by default, to something like /c/Users/username. Unless there's a package library there, it just won't show up in .libPaths().

To work around this, I'd recommend explicitly setting the R_USER environment variable to your Documents folder, C:\Users\username\Documents. I set R_USER in my User Environment Variables - reference here if it helps:

Alternatively, you could override the HOME environment variable in Git Bash, but there might be unintended side effects with that.

export HOME=/c/Users/username/Documents
Rscript -e '.libPaths()'
1 Like

Is it a bad idea to create a symbolic link (or more than 1?) from some of these alternative locations that points to C:\Users\username\Documents\R\win-library\VERSION?

I raise this because sometimes something similar is suggested for handling the location of user's global git config on Windows, due to the same confusion about where the true home directory is:

Also FWIW, last time I wrote about such matters for Happy Git, I found that, in my Windows VM, in R, the HOME env var was set to Documents:

#> [1] "C:\\Users\\JennyVM\\Documents"

#> $HOME
#> [1] "C:/Users/JennyVM/Documents"
#> [1] "C:\\Users\\JennyVM"

I don't have a Windows VM set up at the moment, but that would be an interesting thing to check. If that is a general phenomenon, is that how we explain the difference @ttimbers sees in GitBash inside and outside RStudio?

As for the explicit env var solution, it seems worth discussing whether to set in an OS way (like you describe above) or, the more canonical R way, via .Renviron. Of course if you do it via .Renviron, there's potential for this whole thing to become circular because that is probably looked for in the "home directory"! Perhaps this is why you propose this method, in which case this is a good point to call attention to.

I never thought of that, but it does work! In an administrator Command Prompt, I ran this command to put a symbolic link to C:\Users\username\Documents\R in my home directory:

mklink /d C:\Users\greg\R C:\Users\greg\Documents\R

Then in Git Bash, the link shows up in the library paths, and package installations go into my Documents folder.

$ Rscript -e '.libPaths()'
[1] "C:/Users/greg/R/win-library/3.6"    "C:/Program Files/R/R-3.6.3/library"

I can't think of any downsides with this, but I'd still prefer to set R_USER since it makes your home directory consistent too. With R_USER unset, ~ points to Git Bash's HOME:

> normalizePath("~")
[1] "C:\\Users\\greg"

With R_USER set, ~ points to the Documents folder like it would usually:

> normalizePath("~")
[1] "C:\\Users\\greg\\Documents"

Was this in RStudio? I think Git Bash in RStudio works fine because RStudio sets R_USER for you or something. I noticed that when I open a Git Bash terminal in RStudio, R_USER is already set to my Documents folder. That probably explains the difference here.

I just tried setting R_USER in .Renviron, and it does work as well! There don't seem to be any circular issues. But you do have to put .Renviron under C:\Users\username\.Renviron rather than the usual C:\Users\username\Documents\.Renviron, so there's a potential downside of having to keep two .Renviron files. Considering that, I'd still recommend setting R_USER through system environment variables.

1 Like

Thanks for having this helpful discussion!

One drawback I noticed when setting R_USER to C:\Users\username\Documents (via the GUI/Windows way) is that R from Git Bash still reads .Rhistory, .Rprofile, and .Renviron from C:\Users\username (and strangely does not seem to write to either ~/.Rhistory or ~/Documents/.Rhistory...).

Instead of trying to work around this via symlinks or additional modifications of environmental variables, I tried setting R_USER to C:\Users\username. RStudio now reads and writes packages and configuration files in C:\Users\username, shares command history nicely with R from Git Bash, and I don't need to worry about figuring out which Git Bash env variables I would need to change for terminal R to use the Documents folder properly.

To me this has the advantage of being a single step, which is easy to remember and also explain to learners. However, I am not that experienced in R (especially not on Windows), so please let me know if you see any downsides with this method, and if there are reasons to prefer using C:\Users\username\Documents instead.

I don't claim to know all of the implications, but, yes, I generally share the wish that R -- even on Windows -- would follow *nix-y conventions and not have this gravitational pull towards Documents. I suspect this is a matter of trying to choose the least awful option. It's such a shame that Windows ever introduced this ambiguity about the home directory and that R went all-in on it.

1 Like