On Sun, Apr 21, 2013 at 8:18 AM, Hadley Wickham <h.wick...@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel