ESS does not find Rterm.exe on windows

问题:

I installed R in a directory called "X:\alphaAndOmega\R\R". So Rterm.exe (32-Bit version) is located in "X:\alphaAndOmega\R\R\bin\i386". I know that it's not a 'standard R-directory' and that "standard R-directories", like R-3.0.0 are easily recognized by ESS (at least if I add them to my PATH variable in Windows).

I tried customizing my .emacs file in a way, that ESS would look for Rterm.exe in my non-standard directory, but I wasn't able to do so. I'm absolutely new to emacs and i tried playing around wird some of the following commands:

inferior-R-program-name and ess-rterm-version-paths

But I failed. ESS doesn't find anything.

I use emacs 24.3.1, ESS 13.05 and R 2.15. At the moment my .emacs file contains just one line, so that shouldn't be a problem:

(require 'ess-site)

What can I do to make ESS find my Rterm.exe?

回答1:

There really only is one configuration setting in ess-site.el; I have used that one in the past. Here it is from ess-site.el but note that it is commented-out:

;; If you wish to call other versions of R on a Unix system, ESS 
;; should auto-detect other versions of R, according to matches to the   
;; variable `ess-r-versions' as described in its docstring.  Consider   
;; changing that variable rather than changing inferior-R-program-name  
;; if your version of R is not already auto-detected.                  
;;(setq-default inferior-R-program-name "R")        ; unix systems    
;;(setq-default inferior-R-program-name "Rterm")    ; MS Windows, see below for path
;;(setq-default inferior-R-program-name "C:\\Program Files\\R\\R-2.5.0\\bin\\Rterm.exe")

And I just checked on my work machine, and there Rterm.exe is found by default from the $PATH. I do use the Emacs/ESS/AucTeX bundle by Vincent Goulet which I can wholeheartedly recommend as "it just works."

回答2:

To point ESS to a non-standard R-directory, set the variable ess-directory-containing-R. (This handy variable is a relatively recent feature.) Quoting from the ESS manual:

Changes/New Features in 12.09:

ESS[R]: On Windows, there is now a new customizable variable (currently called ess-directory-containing-R) to tell ESS where to look for the Rterm.exe executables. The name of the variable and the values it can take are both in beta and subject to change. Prior to this variable, ESS searched only in the default installation directory. Setting this variable now tells ESS how to find Rterm.exe executables when they are installed somewhere else.

If I recall correctly, this needs to be done before loading ess-site.el; in any case that's what I have in my .emacs file, which does a fine job of finding all of my R versions, which are all stored under "C:/R/":

(setq ess-directory-containing-R "c:")
;; Add to list of prefixes recognized by ESS. 
;; Matching versions will appear after doing M-x R <TAB> <TAB> 
(setq ess-r-versions '("R-1" "R-2" "R-3" "R-current" "R-devel" "R-patched"))
(load "C:/Program Files/GNU Emacs 23.3/site-lisp/ess/lisp/ess-site.el")

;; Set default R version, (i.e. the one launched by typing M-x R <RET>)
(setq inferior-R-program-name "c:/R/R-current/bin/i386/Rterm.exe")

回答3:

Setting the ess-directory-containing-R variable did not work when I had this problem. Further, when I did a 'describe-variable' on it, on another machine which had a properly working ess-emacs on it, the value was nil, so I don't think that's right.

What DID work is setting the PATH variable in the Windows environment to point to the directory that Rterm.exe lives in, and then restarting emacs.

回答4:

With a default install of ESS (currently 17.11) and R (3.4.4) on Windows, running M-x R tries to execute Rterm.exe in your exec-path and will fail if it is not found there. The automatically generated runners should be used instead eg. M-x R-3.4.4-64bit or simply M-x R-newest.

To use a non-standard R location set ess-directory-containing-R to the base directory to search for R installations. This needs to be done before ess-site is loaded so might require restarting emacs after updating your init file. This will allow the automatically generated runners to be created.