[Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

[Duncan Murdoch]

On 13-04-19 10:03 PM, Gabor Grothendieck wrote:
> On Fri, Apr 19, 2013 at 8:47 PM, Duncan Murdoch
> <murdoch.duncan at gmail.com> wrote:
>> On 13-04-19 5:37 PM, Kevin Coombes wrote:
>>>
>>> Having finally found some free time, I was going to use it to update a
>>> bunch of R packages from 2.15 to 3.0.
>>>
>>> I am running Windows 7, 64-bit professional.  This is on a brand-new
>>> laptop using vanilla settings when installing the operating system.
>>>
>>> Problem 1: I installed R3.0 to the default location (C:\Program
>>> FIles\R\R-3.0.0).  The first thing I tried to do was install
>>> BioConductor.  This failed (permission denied). Thinking that this might
>>> be a BioConductor problem, I then tried to install a (semirandom)
>>> package from CRAN.  This also failed.
>>>
>>> In both cases, when using the GUI, the error message is almost
>>> incomprehensible.  You get a pop-up window that *only* says "Do you want
>>> to use a private library instead?"  Since this wasn't what I wanted to
>>> do I said "no".  Only after the pop-up closes does the command window
>>> print the error message telling me that permission was denied for R to
>>> write to its own library location.
>>
>>
>> This is a standard Windows problem, to stop viruses from modifying installed
>> programs.  The standard Windows solution to it is to run the installer as an
>> administrator, taking personal responsibility for installing the
>> package/virus.
>>
>> Since this is a laptop, you could probably do this, but it's possible that
>> you are not the administrator on your system.  If that's the case, you
>> should ask your administrator to do the install.
>>
>>
>>>
>>> Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a
>>> nonstandard location (C:\R\R-3.0.0).  Now I can successfully install
>>> packages from CRAN and BioConductor (hooray!). But I run directly into:
>>
>>
>> That's another solution, and a third solution is to accept the offer R made,
>> to install your packages somewhere where you as a user have write
>> permission.
>>
>>
>>>
>>> Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R
>>> binary. When R was installed in the default location, ESS worked. When R
>>> 2.15 (or earlier) was installed in the same nonstandard location, I
>>> could get ESS to find the R binaries by including (setq
>>> ess-directory-containing-r "C:") in my .emacs file, but that no longer
>>> works.
>>>
>>> Dumb Fix to Problem 2:  Hack into ess-site.el and put the complete,
>>> explicit path to the correct binary into
>>> (setq-default inferior-R-program-name 'FULLPATHHERE")
>>> which will break as soon as I upgrade R (assuming I am foolish enough to
>>> ever do that again).
>>
>>
>> I can't help you with ESS.
>>
>>>
>>>
>>> Now I am ready to rebuild my R packages.  I have this nice perl script
>>> that goes through the following procedure:
>>>
>>> 1. Set the path to include the correct Rtools directory.  (For reasons
>>> that Gabor Grothendieck has pointed out previously, this is not a
>>> permanent part of the path since doing so would override some built-in
>>> Windows commands.)
>>
>>
>> Just curious:  how often do you use the Windows find command?  We have put
>> instructions in place for people to run the install process with a renamed
>> Rtools find command (which I think is the only conflict). The issue is that
>> more users who want to use the command line commands are familiar with the
>> Unix variant (which came first, by the way) than the Windows one, so
>> renaming the Rtools one would cause trouble for more people.
>
> Its not just find - its also sort. And really R has no business
> clobbering built in Windows commands. This is just wrong and really
> causes anyone who does any significant amount of Windows batch
> programming (or uses batch programs of any complexity) endless
> problems.

Only those people who choose not to solve them in the recommended way.

Duncan Murdoch