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.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.