[ESS] Finding Rterm in R 2.12.0 on Windows

Paul Johnson pauljohn32 at gmail.com
Thu Feb 3 07:43:02 CET 2011

On Tue, Feb 1, 2011 at 4:34 AM, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> Dale W Steele <Dale.W.Steele at gmail.com>
>>>>>>     on Tue, 01 Feb 2011 00:26:00 +0000 writes:

>    > One interesting issue. If I open an empty file test.R and
>    > navigate via the ESS menu, Ie. "Start Process:Other and select
>    > the 64 bit version, then the following text appears in the
>    > buffer:
>    > "ESS [S(R): C:/Program Files/R/R-2.12.1patched/bin/i386/Rterm.exe] starting data directory?"
>    > Although this appears to point to the 32-bit version, the 64-bit
>    > version opens in the R buffer when I hit enter.
> Yes. That is actually another glitch, not at all related to
> Windows or even R: Inside "[..]" the S or R version displayed is
> sometimes wrong, i.e. the "previous" version instead of the one
> that will be taken.

I've been watching this thread with interest.  Lately I've installed
Emacs and R on about 15 student computers with various versions of
windows. I've run into all of the various problems described in this
thread.  Emacs/ESS can't find R, etc. There are many ways to break
this chain of tools, some of which we could simplify for the ordinary
average non-computer science grad student.

Here are suggestions I am thinking of making to the R for Windows
packagers. Please tell me what you think:

1. The DEFAULT install path for R should NOT have an R version number
in it. It should only be C:/Program Files/R.  I propose to do that,
either for 64bit or 32bit installs, even on a Win7 system, where the
system seems to prefer to install in C:/Program Files (x86)/R.   For
ordinary users, only one version of R will be desired, and expert
users can add the version number to the path if they want several

Benefits.  Supposing that the R packaging does not change the location
of Rterm.exe, we can put the right folder in the PATH and forget about
it.  We need either bin (old packaging), or bin/i386 or bin/x64. That
can be added to the system PATH and it will not have to be revised
when R is updated.  And ESS will always be able to find R, since it
will be in the path.

This is a *good thing* because sometimes other programs--not just
Emacs/ESS--will want to run R executables.

2. The update.packages function should default to checkBuilt=T, so
users who update R will, unless they actively resist, get the packages
that match their installation.

The current install path, including the version number, creates a very
confusing scenario for updates of packages.  Did you ever study the R
for Windows FAQ discussion on what a user is supposed to do about the
old lib dir and packages? I'm pretty good at computing and I can
barely figure it out.  By adding checkBuilt=T, we completely eliminate
that problem.

These suggestions bring the Windows install closer to the default
Unix/Linux install. Install R in one place, don't keep version numbers
in the install path, etc.

Well, what do you say?

Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

More information about the ESS-help mailing list