This has now been mostly fixed in R-devel. What remains to be resolved is that some packages with custom make files cannot be installed from source (when R is installed into a directory with space in its name and short file names are not available) Tomas On 10/17/2017 10:37 AM, Tomas Kalibera wrote:> Hi Zach, > > thanks for the report, I can reproduce the problem and confirm it is a > bug in R and will be fixed. > > Hopefully it only impacts few users now. The workaround is to create > the short name for the directory where R is installed, using "fsutil > file setshortname" (for all elements of the path that contain space in > their name). One can revert this by setting the shortname to an empty > string (""). At least for the latter one may need to boot in safe mode. > > Best > Tomas > > > On 09/17/2017 08:23 PM, Zach Bjornson wrote: >> Hello, >> >> R appears to assume that Windows drives have short file names (SFN, 8.3) >> enabled; for example, that "C:/Program Files/..." is addressable as >> "C:/Progra~1/...". Newer versions of Windows have SFN disabled on non-OS >> drives, however. >> >> This means that if you install R on a non-OS drive, you >> - can't start R.exe from the command line. >> - consequently, anything that attempts to spawn a new R process also >> fails. >> This includes a lot of the commands from the popular devtools >> package. More >> discussion and background: >> https://github.com/hadley/devtools/issues/1514 >> >> I don't have access to bugzilla to file this there. >> >> Thanks and best, >> Zach >> >> ????[[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > >
An update on this. Writing R Extensions does not recommend to have a space character in R_HOME. This means that on Windows one either should have SFN enabled (which is still the common case), or install into a directory that does not have a space in its name (so specifically not into "Program Files"). This recommendation unfortunately needs to stay for now. WRE recommends that Makefiles are written to be robust against space characters inside R_HOME. All path names passed from a Makefile to the shell should be quoted at least if they include R_HOME. Make "include" directives should not be used on path names that are derived from R_HOME, but one should instead use the "-f" option multiple times when recursively invoking make. Maintainers of packages that use "include" with R_HOME have been notified. Unfortunately, the number of packages that do not quote pathnames with R_HOME in Makefiles is rather large, so fixing will take some time. Currently, R-devel should build fine on Windows with R_HOME including space, including all base and recommended packages, and tests for these packages should pass even though this is not regularly tested. If you find a case when this does not work, please submit a bug report. Thanks Tomas On 10/20/2017 04:29 PM, Tomas Kalibera wrote:> > This has now been mostly fixed in R-devel. What remains to be resolved > is that some packages with custom make files cannot be installed from > source (when R is installed into a directory with space in its name > and short file names are not available) > > Tomas > > > > On 10/17/2017 10:37 AM, Tomas Kalibera wrote: >> Hi Zach, >> >> thanks for the report, I can reproduce the problem and confirm it is >> a bug in R and will be fixed. >> >> Hopefully it only impacts few users now. The workaround is to create >> the short name for the directory where R is installed, using "fsutil >> file setshortname" (for all elements of the path that contain space >> in their name). One can revert this by setting the shortname to an >> empty string (""). At least for the latter one may need to boot in >> safe mode. >> >> Best >> Tomas >> >> >> On 09/17/2017 08:23 PM, Zach Bjornson wrote: >>> Hello, >>> >>> R appears to assume that Windows drives have short file names (SFN, >>> 8.3) >>> enabled; for example, that "C:/Program Files/..." is addressable as >>> "C:/Progra~1/...". Newer versions of Windows have SFN disabled on >>> non-OS >>> drives, however. >>> >>> This means that if you install R on a non-OS drive, you >>> - can't start R.exe from the command line. >>> - consequently, anything that attempts to spawn a new R process also >>> fails. >>> This includes a lot of the commands from the popular devtools >>> package. More >>> discussion and background: >>> https://github.com/hadley/devtools/issues/1514 >>> >>> I don't have access to bugzilla to file this there. >>> >>> Thanks and best, >>> Zach >>> >>> ????[[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >
On 7 December 2017 at 17:56, Tomas Kalibera wrote:
|
| An update on this. Writing R Extensions does not recommend to have a
| space character in R_HOME. This means that on Windows one either should
| have SFN enabled (which is still the common case), or install into a
| directory that does not have a space in its name (so specifically not
| into "Program Files"). This recommendation unfortunately needs to
stay
| for now.
|
| WRE recommends that Makefiles are written to be robust against space
| characters inside R_HOME. All path names passed from a Makefile to the
| shell should be quoted at least if they include R_HOME. Make
"include"
| directives should not be used on path names that are derived from
| R_HOME, but one should instead use the "-f" option multiple times
when
| recursively invoking make. Maintainers of packages that use
"include"
| with R_HOME have been notified. Unfortunately, the number of packages
| that do not quote pathnames with R_HOME in Makefiles is rather large, so
| fixing will take some time.
|
| Currently, R-devel should build fine on Windows with R_HOME including
| space, including all base and recommended packages, and tests for these
| packages should pass even though this is not regularly tested. If you
| find a case when this does not work, please submit a bug report.
Why does the Windows installer default to using a directory with spaces?
Related (but moderately more advanced), why does R still install
"everything"
under one (versioned) directory so that uninformed users on upgrade
"miss"
all previously installed packages?
Why not (with space for exposition here, imagine s/ // everywhere below)
$SOMEROOTDIR / R /
R-a.b.c/ # before
R-a.b.d/ # d > c, here
site-library/ # with .libPaths having this preset?
I don't really care as I manage to work mostly / entirely on another OS, but
I just don't understand why we do not put two and two together. But I am
likely unaware of some salient issues.
In any event, I appreciate the thankless work of those taking care of Windoze
(ie Tomas, Jeroen, Duncan (now ex-officio), Brian, ...)
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org