[ESS] Finding Rterm in R 2.12.0 on Windows

[Paul Johnson]

On Thu, Feb 3, 2011 at 12:06 PM, RICHARD M. HEIBERGER <rmh at temple.edu> wrote:
> I think it is easy.  The Windows R installation puts a shortcut "R
> 2.12.1.lnk" on the desktop.
> That might be sufficient as is.
>
> That shortcut could also be copied to any arbitrary place, say c:/program
> files/R.lnk, and
> on 64-bit machines, we could also have R32.lnk and R64.lnk, with R.lnk
> pointing to
> the 32-bit system as Martin suggested earlier in this thread.  The shortcut
> can be
> programmatically executed from the MSDOS cmd window, and from the shell exec
> mechanism.
>
This does not fix a major part of the problem.  When the user installs
a new version of R, it goes into the version-specific directory, the
user has 2 R's, can't figure what to do about the installed packages,
etc.

I guess, at the base of it, I don't see why you want the versioning in
the install dir's name, except for developers who need to keep several
installed at once.

And, if we persist installing into version specific paths, we can't
ever just put one permanent R directory in the PATH variable, and we
have to keep wrestling with the problem that the user wants to run
Rterm.exe from the "command line" and it is not in the path so it does
not work.

Other users mention mischief in Win7 that I don't see.   On my win7
systems, either 64 bit or 32 bit, there is no trouble at all
installing the 32 bit version of R into "C:\Program Files\R" and
putting into the path "C:\Program Files\R\bin\i386".  I don't have the
complications people mention about the system resisting that choice.
The system does have the two parallel sets of directories, ("Program
Files" and "Program Files (x86)",  but on either  64 or 32 bit
systems, the 32 bit R gets found.  (I install the 32bit because the R
web site still recommends that, except for RODBC users).

What is the other problem you are referring to?

The only big Vista/Win7 complication I see is that "VirtualStore"
disaster. When I try to configure something in ESS or install an R
package and I'm not acting as the administrator, then Windows tries to
"fool me" by installing the app in a hidden part of the user  account,
in a folder named like
C:\Users\pauljohn\AppData\...\LocalSettings\VirtualStore\.  Then it
creates an "illusion" that it did install into C:\Program Files\R by
re-routing my user requests from the C:\Program Files area into that
VirtualStore.  So after I log off, then other users come along and R
packages or Emacs ESS config changes I made are not available to them.

It really pissed me off when I spent an afternoon customizing Emacs
and all the changes seemed to disappear when somebody else logged on.
It seems willing to let you edit files in C:\Program Files\Gnu Emacs
23.2\site-lisp\site-start.d, but  the changes you make by hand get
diverted into that hidden VirtualStore thing.  But, as long as you are
aware of this shell game, you can run Emacs "as administrator" so it
will actually make the changes you want in the Program Files
hierarchy. Well, it is still a ghastly, horrible setup. But I'm warned
about it now.

> On Thu, Feb 3, 2011 at 12:54 PM, Rodney Sparapani <rsparapa at mcw.edu> wrote:
>
>> On 02/ 3/11 12:43 AM, Paul Johnson wrote:
>>
>>>
>>> 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
>>> installed.
>>>
>>> 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.
>>>
>>>
>> Hi Paul:
>>
>> I agree.  But, can you actually do #1?  I thought there was some Bill
>> Gates slight-of-hand going on that prevents you from doing that.  If
>> not, then please enlighten us.  I've only been using 7 occasionally
>> and these idiosyncrasies are very annoying to anyone who has used
>> XP (or NT/OS X for that matter).
>>
>> Rodney
>>
>>
>> ______________________________________________
>> ESS-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/ess-help
>>
>
>        [[alternative HTML version deleted]]
>
> ______________________________________________
> ESS-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>



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