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

[Gabor Grothendieck]

On Sun, Apr 21, 2013 at 8:18 AM, Hadley Wickham <h.wickham at gmail.com> wrote:
>> The problem is that if you don't just use the PC for running R but use
>> it to run other programs too then any program and that utilizes
>> Windows batch scripts making use of find.exe or sort.exe likely won't
>> work if Rtools is on your path.
>>
>> The fact that devtools, batchfiles and Rcpp have workarounds mitigates
>> it somewhat but the problem should be fixed so it works out-of-the-box
>> once and for all.
>
> I guess I don't see the advantage of that approach (except perhaps for
> simplicity), compared to using the registry to store path information
> and then using environmental variables to set it when needed. It would
> be nice if Rtools didn't override existing windows executables, in the
> same way it would be nice if windows worked like linux out of the box.
> But since it doesn't, and since in general adding more and more
> directories to the path makes it more and more likely for some
> conflict to arise, I think Rtools current approach is very reasonable.

Because it can conflict with other Windows software unless you add a
layer over it.  What other popular software that runs on Windows has
these problems?  I can't think of any.  The closest I can come up with
was that for a short time after git was ported to Windows it would
change the font of the Windows console but there was an immediate hue
and cry about it having no business messing with the rest of Windows
and it was quickly rectified.

Accepting these infelicities just gets one onto a slippery slope.  For
example, as far as I know devtools and Rcpp don't have any current
problems but that could easily change in the future since they keep
databases of Rtools configurations which must be manually updated by
their developers as Rtools evolves -- if Rtools changes they could
stop working for periods of time until new versions are produced.
R.bat in batchfiles was just re-written this year so it is a bit more
robust to such changes but even it would have to be modified if the
changes in Rtools were of sufficient magnitude.  I don't blame these
tools for this but surely this is a symptom that something is
fundamentally wrong with the entire approach since the tight coupling
of what should be independent modules results in the need for ongoing
maintenance.

Some good work was done to rid R and Rtools of dependence on perl but
this effort should not stop there and needs to continue in order to
reduce and eliminate the dependence on third party tools that cause
problems.

(By the way, regarding registry values and environment variables,
R.bat in batchfiles will look at the registry and at environment
variables but it will work even if no registry values or environment
variables have been set by the user provided one uses standard
locations for R and Rtools.  That is, in fact, how I run my own
configuration on Windows.)

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com