Recently I used the jenv VERSION control tool in Ubuntu16LTS.
This is probably the first time I have used this tool.
Once installed, I can switch versions using jenv local VERSION,
but jenv global VERSION does not seem to work.
How to solve it?
in the first terminal window：
zx#zx-virtual-machine:~$ jenv versions
system
11
* 12 (set by /home/zx/.java-version)
openjdk64-11
openjdk64-12
zx#zx-virtual-machine:~$ jenv version
12 (set by /home/zx/.java-version)
zx#zx-virtual-machine:~$ jenv global 11
then,i close the first terminal window,and open another teminal windows:
zx#zx-virtual-machine:~$ jenv version
12 (set by /home/zx/.java-version)
so,it didn't work for me.How to solve the problem?
1.Set the jdk version for a specific directory. The priority is greater than global. If the local version of the current directory is specified, the local version prevails and the global version is ignored.
2.You can understand the difference between "jenv local" and "jenv global" by going to ubuntu's home"~" and root directory "/" and looking at "jenv version"
Related
When running the checks for my R-package (via devtools::check()) I face the warning ''qpdf' is needed for checks on size reduction of PDFs. I found this question were it was suggested (if I understood the answer correctly) to run Sys.which(Sys.getenv("R_QPDF", "qpdf")) and see whether qpdf is found or not. In my case this just returns
qpdf
""
so, I think I didn't install qpdf correctly. Unfortunately it seems to be quite complicated to install qpdf on Windows. My first side question is: does it really is so painful and complicated to install qpdf for Windows or is there an easy solution?
I've followed the instructions until it is said to add C:\MinGW-w64\bin and C:\MinGW-w64\lib\mingw to the PATH variable. But then I don't find further specific instructions to install qpdf, only about how to build qpdf with different other programs. The second side question is: is my assumption correct that after I've build qpdf it is installed? But the real question is: What is the best way to build qpdf? I tried the ./config-mingw32 and ./config-mingw64 commands from the section "Building with MinGW" in my C:\MinGW\msys\1.0\bin\bash.exe but got the error messages ./config-mingw32: No such file or directory and have no idea how to fix this issue.
I'm using Windows 10, R version 3.3.2 Patched (2017-01-07 r71934) -- "Sincere Pumpkin Patch" and RStudio 1.0.136.
You basically do not need to build the file on windows. Please follow three steps below:
Download qpdf for windows from https://sourceforge.net/projects/qpdf/?source=typ_redirect
Extract files in a temp folder
Copy the contents of the bin folder to %SystemRoot%\System32
job done!
Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"C:\\WINDOWS\\SYSTEM32\\qpdf.exe"
To flesh out an answer provided elsewhere:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 10.0.1 is listed here).
Rather than copying files to C:/Windows/System32, a potentially safer option is to extracted the zipped qpdf directory to C:\Program Files. If you do this, you'll need to add C:\Program Files\qpdf-version_number\bin to your system PATH under the environment variables.
To do this within R, run Sys.setenv('PATH' = paste0('C:\Program Files\qpdf-version_numer\bin;', Sys.getenv('PATH')))
To do this in Windows, open the start menu, type "edit the system environment variables" to open the System Properties, and at the bottom of the "Advanced" tab click "Environment variables". Find the "Path" entry under "System variables" and click "Edit". Then, re-start R so it picks up the modified PATH.
One further step may be required to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning, as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. This done, Windows will recognize the file as safe to run and allow other software, including R, to use it.
I am using an Rstudio Server (0.98.490) on a CentOS machine, that uses the default installation in the machine which is an older version of R. I also have a newer version of R compiled elsewhere in the system. Can I, as a non-root user, tell Rstudio to use the new installation instead of the old one when I start a session?
I'm not sure if there are any peculiarities for CentOS, but I believe you should be able to change your ~/.profile or ~/.bash_profile file to include the following line: export RSTUDIO_WHICH_R=/path/to/desired/compiled/R.
You can see which version of R RStudio is currently running by entering which R into a terminal. the export command listed above should change it to your desired build.
These links might help:
https://support.rstudio.com/hc/en-us/articles/200486138-Using-Different-Versions-of-R
Running newer version of R from terminal when older version is invoked by default
Hope this helps
The first answer was relevant RStudio, not rstudio-server as the question asks. The question is addressed in the section "RStudio Desktop and RStudio Server Open-Source".
However, adding a line like export RSTUDIO_WHICH_R=/usr/local/bin/R to my ~/.profile and ~/.bash_profile does not actually seem to affect rstudio-server for me. So I am giving up for now. The Pro version seems to have other options, as listed here.
Starting in RStudio Server 1.3 (newest version is 1.4.1106, released February 22, 2021), a user’s preferred version of R can be specified in the rstudio-prefs.json file in the global-level /etc/rstudio folder or in the user-level ~/.config/rstudio folder.
See https://blog.rstudio.com/2020/02/18/rstudio-1-3-preview-configuration/ and https://docs.rstudio.com/ide/server-pro/session-user-settings.html for user setting options in newer versions of RStudio Server.
See https://support.rstudio.com/hc/en-us/articles/200716783-RStudio-Release-History for RStudio release history and https://www.rstudio.com/products/rstudio/download-server/redhat-centos/ for Red Hat downloads of the newest version of RStudio Server.
I have a problem downloading R in my mac which I have been dealing with for many hours now.
My purpose is to use propensity score matching in SPSS (from source forge). I am using SPSS version 22 on my mac OS X yosemite 10.10.5.
After reading a lot on the different sites I need to use R.2.15 for SPSS 22 in order to use the psmatching 3.03 on source forge.
However, I cannot seem to install R 2.15 when I run the installation package. When I am going to select destination on the macintosh HD, it says that R2.15.0 for Mac OS X 10.5 or higher can’t be installed on this disk. How is this possible? My OS X version is higher than the demanded version for R 2.15.
Any ideas how to make the installation?
I've run into this problem myself: SPSS versions require very specific versions of R to be installed for the R Integration plug-in to work. An older or newer version of R will not suffice.
I think the installation error is due to the old R installer's attempt to verify a sufficiently high OS X system version. But it doesn't recognize 10.10+ as being higher than 10.9 (or 10.5 for that matter).
The link below has information about disabling OS X El Capitan's System Integrity Protection, in order to change the OS X file /System/Library/CoreServices/SystemVersion.plist, so that a false system version can be reported to the installer.
https://forums.developer.apple.com/thread/4138
A safer method might be to manually place the files from R's 2.15 installer. There's an apparent complication with my attempt at that, though. I opened the R 2.15.pkg installer file, found a file 'payload' inside, used 'tar -xzvf Payload' to extract contents, and moved those contents into /Library/Frameworks/R.framework/Versions/2.15. In retrospect, it may be most useful to temporarily re-alias "Current" in the R.frameworks folder so that it points to 2.15 version while the installer completes. Instead, I did the following to get around installer error messages I found in the installer log file, which worked for me:
The SPSS Essentials for R installer reported that the install location does not contain R 2.15. Examining the error log files led me to believe that the installer's attempt to verify the R version inappropriately navigated to the "Current" version (aliased to a specific version, likely not R 2.15 if 2.15 was installed manually), even if the directory for 2.15 was specifically entered into the installer. It then seeks a couple of i386 subdirectories that no longer exist as of R 3.2.2. So (for my case) I manually created "/Library/Frameworks/R.framework/Versions/3.2/Resources/bin/exec/i386" and copied version 2.15 of the R unix executable, and did similarly for "/Library/Frameworks/R.framework/Versions/3.2/Resources/etc/i386", copying in the ldpaths file that the installer seeks. Doing so finally allowed the SPSS Essentials for R installer to complete. In retrospect, temporarily re-aliasing "Current" in the R.frameworks folder might have been a more direct approach, but I haven't tried that as of right now.
For what it's worth, I was able to install an older version of R (for a different purpose, but I found this page while trying to figure it out), without having to temporarily change the version of OS X (or macOS) on my system. That seemed dangerous to me, and I wanted a simpler fix.
What worked for me was extracting the installer pkg, modifying the version check in there, and then packaging it up again.
Downloading the pkg installer from CRAN
open Terminal and cd to the directory where the installer is: e.g.,
cd ~/Downloads
use pkgutil to expand the pkg file you downloaded
pkgutil --expand R-2.15.0.pkg R-2.15.0
This creates a folder named R-2.15.0 (You can name it whatever you want in the command above). In that folder is a text file called Distribution.
Open the Distribution file in a text editor (e.g., TextEdit), and
modify the function at the beginning that checks the version of OS
X. for example, if it requires Leopard, there will be a line that
looks like this:
if(!(my.target.systemVersion.ProductVersion >= '10.5.0')) {
...
}
Notice that version string for comparison is a string (not a number!), so any version past 10.9 (10.10 and up) will fail that check ('10.10' sorts between '10.1' and '10.2', which is less than '10.5').
All I did was change the minimum version here ('10.5.0') to '10.1'. So the same line reads:
if(!(my.target.systemVersion.ProductVersion >= '10.1')) {
Save the Distribution file.
Go back to terminal and re-package the directory you created in step 3:
pkgutil --flatten R-2.15.0 R-2.15.0-HACKED.pkg
You can call the new pkg whatever you want, as long as you will recognize it.
The resulting package (R-2.15.0-HACKED.pkg, in this example) will now run on any version of OS X higher than or equal to the version you specified (in this case, 10.1 and up).
Disclaimer: I actually tested this with R-2.12.0 (and it worked), but I provided example code for R-2.15.0 to answer the original question. It should be similar with any R installer pkg for OS X that uses a similar version string to check for compatibility before installation.
I have downloaded and installed R.
I see it here in Applications folder (I am on a Mac with Yosemite):
Fine. I can launch R.app and indeed, yes, I am running the version I want, which is 3.2.2:
So far so good. I can even open up RStudio and see that I am indeed running 3.2.2!
So after all this, I simply go to my terminal, type
r
and turns out I am running 3.1.1!
I understand the old user of my work computer probably had installed this older version.
So here's what I'm wondering:
If I just installed R.app correctly, WHY is this old version still living on my computer, and how do I get rid of it?
If this is some sort of $PATH thing, WHY doesn't the most obvious location for an app, the Applications folder, get checked for the existence of R?
Thanks.
UPDATE
Turns out the old version of R has been installed by homebrew.
Typing which r in your terminal will give you where the shell thinks R is. Then, you need only uninstall it from that location.
Since we've determined it's homebrew, all you need to do now is brew unlink r; rm -Rf /usr/local/Cellar/r/3.1.1 and you should be golden after you rehash in your shell.
It worked because you installed it using homebrew. To remove it from the system, you must first unlink it and then remove it from the system.
I recently upgraded to Architect version 0.9.7 on my Win 7 machine. However, after starting Architect, the RJ console wouldn't launch and I got the error message:
‘Launching the R Console was cancelled, because It seems starting the R engine failed.”
Please make sure that R package 'rj' (2.0 or compatible) is installed and
that the R library paths are set correctly for the R environment
configuration 'Embedded R Server'.
I installed the packages ‘rj’ and ‘rj.gd’ through the RTerm run console (which does happen to work) within Architect using the command suggested on www.walware.de:
install.packages(c("rj", "rj.gd"), repos="http://download.walware.de/rj-2.0")
Then, I restarted windows, and restarted Architect. Same error message. I zoomed in on the details of the error message and noticed the following line:
SEVERE: Path to rj package not found. Use R_LIBS or java property
'de.walware.rj.rpkg.path' to specify the location.
So I opened an RTerm run console to check whether any of my .libPaths() locations contains the directories ‘rj’ or ‘rj.gd’. Oddly enough, they do. My first .libPaths path contains both packages. So that doesn’t seem to be the reason.
How could this be fixed?
I received prompt and helpful feedback from Open Analytics (thanks!), who informed me that the problem is due to changes in Java 8. With Java 7, Architect works fine. The next release of Architect will incorporate the changes in Java 8.
In order to get it work with Java 7, enforce the use of a specific Java Runtime, by using the -vm argument in the architect.ini file as follows:
-vm
C:\Program Files\Java\jre7\bin\javaw.exe
(mind the line break, which is required)
This is particularly useful if you have several Java versions on your system where the default Java is not suitable for use with Architect. The architect.ini file is found directly at the top level of the installation folder of Architect. You can find out where this is by looking at the Properties of the Architect shortcut on your desktop.
N.B. the -vm argument should be put before the -vmargs argument otherwise it is simply ignored!
N.B. examples of -vm specification on GNU/Linux and Mac OS X:
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Linux_Example
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Mac_OS_X_Example