[R] Cannot use R on Windows when installed to an external drive with a space in the path

[Tomas Kalibera]

On 10/22/2018 07:15 PM, Ivan Krylov wrote:
> This is a bin\R.exe + bin\Rscript.exe bug.
Please note this has been fixed in later versions of R, quoting has been 
added. If you can find some corner case in which the current quoting 
(R-devel) is incorrect on Windows, in the front-ends or anywhere else, 
please send a bug report with a reproducible example.

But please keep in mind my comment that some packages will not be 
working with space in the name of R home directory. Some packages will 
not build from source. CRAN has been checking for the most obvious cause 
of this (certain use of include directives in make files), but it is 
still not safe to use R on file systems without SFN.

Best,
Tomas
>
> On Windows, where the system call to create a process only takes one
> command line string instead of an array of command line parameters[0]
> (and the C runtimes usually call CommandLineToArgvW[1] behind the
> scenes to get an array back), execv() does nothing to prepare a
> properly-quoted command line and just concatenates its arguments[2].
> Moreover, Windows version of execv() is effectively undocumented[3],
> nor there is any information about the suggested replacement[4].
> (You can call it a Windows bug instead.)
>
> Short file names are not a guaranteed solution, because they may
> not be available at all on some filesystems[5] (which is how this
> error has been encountered). In the general case, "argument quoting
> hell"[6] is unavoidable on Windows, but the code from [2] implements
> the proper conversion from an array of strings to a single quoted
> command line, ready to be parsed by the launched process.
>
> char* getRHOME(int m) in src/gnuwin32/rhome.c tries to return a short
> path (assuming it won't contain spaces). This is used by rcmdfn() from
> src/gnuwin32/front-ends/rcmdfn.c to system() a command line built with
> no quoting, causing the error. rcmdfn() is called from
> src/gnuwin32/front-ends/R.c, which seems to contain the entry point for
> R\R-3.3.3\bin\R.exe.
>
> Fortunately, in src/unix/Rscript.c the whole mess seems to be avoided by
> having it directly include rterm.c and then call AppMain() on Windows,
> passing the command line parameter array. Same goes for
> src/gnuwin32/front-ends/graphappmain.c. The corresponding executables
> reside in the architecture-specific subdirectory of ...\bin\.
>
> So if you run Rgui.exe, Rterm.exe or Rscript.exe from
> R-3.3.3\bin\i386 instead of R-3.3.3\bin, no extra cmd.exe processes
> should be spawned and the badly-formed system() should be avoided.
>