Surely the idea of having a separate windows version of R is that it works in a very Windows-like way and that would preclude having conflicts with standard utilities on Windows. To me this is one of the most annoying things about R since I do use other Windows software and that includes software that conflicts with R. In fact, one of the Linux distros I tried to install on top of Windows conflicted with R since its setup.bat file used find and that's Linux! After spending quite a bit of time being frustrated with the installation I finally realized R was the culprit and was really cursing R for having wasted so much of my time. Windows should be setting the standard, not R.
I don't have this sort of conflict problem with any of the other software I use except R. One other point. The multiple UNIX tools in a single executable I mentioned is called busybox: http://busybox.net/ Its intended for embedded systems and specific to UNIX systems although its web page claims its not that hard to get it to work on Windows. For example, this UNIX-on-a-floppy distro, tomsrtbt, uses it: http://www.toms.net/rb/ I mention busybox because you indicated that you were concerned about the size of the R distro on Windows. On 5/5/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 05/05/2007 8:00 AM, Gabor Grothendieck wrote: > > I think that should be the default in order to protect the user. Protecting > > the user from this sort of annoying conflict is important for a > > professionally > > working product that gets along with the rest of the Windows system. > > I don't, because R building requires simulation of a subset of a Unix > environment, so in case of a Unix/Windows conflict, Unix should win. > For example none of the Makefiles use backslashes as path separators, > they all use Unix-style forward slashes. > > Duncan Murdoch > > > > > > On 5/5/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >> On 04/05/2007 9:32 PM, Gabor Grothendieck wrote: > >>> It certainly would be excellent if installing perl could be eliminated. > >>> > >>> One additional thing that I really dislike about the R installation is > >>> that > >>> one needs "find" on one's path and that conflicts with "find" on Windows > >>> so other applications unrelated to R that use scripts can suddenly break > >>> because of R. If that could be solved at the same time it would be nice. > >> At a minimum we should be able to wrap the calls to find in a macro, so > >> you could change the macro in MkRules and rename your copy from Rtools > >> to remove the conflict. I'll take a look. > >> > >> Duncan Murdoch > >> > >>> On 5/4/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>>> On 04/05/2007 4:25 PM, Greg Snow wrote: > >>>>> I have used the pp/par combination for Perl before. It is pretty > >>>>> straight forward to convert an existing perl script into a stand alone > >>>>> windows executable. > >>>>> > >>>>> Both the Activestate licence and the Perl Artistic licence allow for > >>>>> embedding a script and perl interpreter together and distributing the > >>>>> result. > >>>>> > >>>>> The current perl script(s) used for the R package build package could > >>>>> easily be converted to a 'stand alone' windows executable and be > >>>>> distributed with Rtools for those who do not want to install Perl > >>>>> themselves. > >>>>> > >>>>> The only drawback is that even a "Hello World" script will result in > >>>>> over a meg sized executable (due to the perl interpreter being > >>>>> included). > >>>> I took a quick look at the PAR page on CPAN, and it seems possible to > >>>> build a DLL that incorporates the interpreter, and then each individual > >>>> script .exe could be much smaller. I'll see if I can get that to work; > >>>> it would be really nice to be able to drop the Perl requirement. If we > >>>> could do that, I'd include the command line tools plus the compiled > >>>> scripts with the basic R distribution, so you could easily build simple > >>>> packages. The Rtools.exe installer would then just need to install the > >>>> MinGW compilers for packages containing compiled code, and a few extras > >>>> needed for building R. > >>>> > >>>> I don't really know Perl, so I might be asking for advice if I get stuck. > >>>> > >>>> Duncan Murdoch > >>>>> ________________________________ > >>>>> > >>>>> From: [EMAIL PROTECTED] on behalf of Gabor Grothendieck > >>>>> Sent: Fri 5/4/2007 11:55 AM > >>>>> To: Doran, Harold > >>>>> Cc: r-help@stat.math.ethz.ch; Duncan Murdoch > >>>>> Subject: Re: [R] [SPAM] - Re: R package development in windows - > >>>>> BayesianFilter detected spam > >>>>> > >>>>> > >>>>> > >>>>> Just googling I found this: > >>>>> > >>>>> http://www.perlmonks.org/?node_id=186402 > >>>>> > >>>>> On 5/4/07, Doran, Harold <[EMAIL PROTECTED]> wrote: > >>>>>>> The best, of course, would be to get rid of Perl altogether. > >>>>>> In Python, it is possible to make standalone executables. Is it > >>>>>> possible > >>>>>> to also do this in Perl, then one could eliminate a perl install. Or, > >>>>>> is > >>>>>> it possible to use Python to accomplish what perl is currently doing? I > >>>>>> may be getting in over my head here since I really don't know what perl > >>>>>> is doing under the hood. > >>>>>> > >>>>>> Harold > >>>>>> > >>>>> ______________________________________________ > >>>>> R-help@stat.math.ethz.ch mailing list > >>>>> https://stat.ethz.ch/mailman/listinfo/r-help > >>>>> PLEASE do read the posting guide > >>>>> http://www.R-project.org/posting-guide.html > >>>>> and provide commented, minimal, self-contained, reproducible code. > >>>>> > >>>>> > >>>>> > >> > > ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.