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

[Gabor Grothendieck]

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.