Is this an RStudio app bug, or an RStudio bug, or an R bug?

in setup_env() of our script.sh.erb for the interactive RStudio app, we export $R_LIBS_USER using the %v specifier

export R_LIBS_USER='~/R/%v'

…and it seems to work as desired. But curiously, and somewhat intermittently, a literal %v directory will be created in addition to the expected expanded directory (either immediately, or after executing a few commands in Rstudio)…

[jason ~/R ]$ ls -ald *
drwxr-xr-x 2 jason jason 10 Jan 15 12:21 3.5.2
drwxr-xr-x 2 jason jason 10 Jan 15 12:21 %v

…and changing R_LIBS_USER to use other specifiers will have a similar outcome. Poking through OOD’s code for this app, I feel like it must be an RStudio bug, although my google-fu has turned up no other complainants.

Can anyone verify if their app does something similar?

Jason, here’s a sort of similar question - though when I first checked i didn’t have the ~/R/%v directory so I didn’t stumble upon issue this until now.

I am able to replicate by adding R_LIBS_USER to my ~/.bashrc so I suspect this is a little on us here where maybe it’s a bash evaluation thing? or maybe the --r-libs-user arguement is broken in RStudio and if we just had the environment variable set it would work better? I’ll test the last bit out now.

In either case, I’ve use ~/.Renviron with a lot of success. Of course the onus is on the user to have that file, but it removes bash from the equation.

Thanks for the quick response!! I hadn’t even realized the --r-libs-user argument was whole other thing, despite having noticed that repeatedly (smacks self) … but I could certainly see that making sense. In any case, I appreciate knowing it isn’t just me, so thank you!

You may want to add an OS tag. Don’t use the R variable as that simply calls things Windows/MAC/Linux. Grab it from something like lsb_release -ir | awk '{ print $NF"-" }' | tr -d '\n' I was adding this to the R version hence the added “-”

FYI, the reason I say this is I have seen a conflict between the R-geospatial app (modified from Rocker, Debian) and our Centos packages. Could have been an OpenBLAS vs MKL difference, but for us, tagging with OS resolves it.

Hey where you ever able to resolve this? Did Bob’s notes help?

Honestly it has yet to create even a single user-ticket, so I never really messed with it, and was happy just to know that you’d been able to re-create the issue and it wasn’t all in my head :slight_smile:

I did/will note Bob’s workaround, if it becomes an issue, but this is pretty low on my list at the moment.

I’m not sure if it’s appropriate to mark this topic as solved, but I personally am not bothered by it!

The average user won’t notice much more than an odd loss of the libraries they thought they installed. Until you provide an updated R and it tries to use the libraries in ‘%v’ and the libraries all error out due to version conflicts.