Skip to content

Error when calling (R 4.0.x on Windows) from Python

2 messages · Tomas Kalibera, Bill Dunlap

#
A reproducible example:

system("\"C:\\Program Files\\R\\R-4.0.3\\bin\\R.exe\" -e commandArgs() 
 >out")? # does not create "out"
system("\"C:\\Program Files\\R\\R-3.6.3\\bin\\R.exe\" -e commandArgs() 
 >out")? # creates "out"

Note that this does not create "out", either:

system("\"C:\\Program Files\\R\\R-3.6.3\\bin\\x64\\Rterm.exe\" -e 
commandArgs() >out")

I think redirections should be left to the shell, so e.g. those calls 
from Python should use "os.system" if they needed redirection, as Duncan 
suggested.

I see that both R.exe and Rterm.exe give "Usage: Rterm [options] [< 
infile] [> outfile] [EnvVars]", which may be confusing to programmers 
invoking R without a shell, but then talking there about invocation via 
shell could confuse typical users, instead.

My best guess is that the redirection in R.exe in 3.6 worked rather by 
accident, as a consequence of that R.exe internally invoked (and still 
invokes) Rterm.exe via the shell, but R.exe did not protect all 
arguments from expansions from that internal shell invocation. If 
redirection was meant to work without external shell, it would have 
instead been implemented explicitly also in Rterm.exe.

My change 77926 made sure that all arguments to that internal shell 
invocation were protected, following bug reports such as PR#17709, where 
users had "&" in their file names. Therefore, this works, executing file 
code&.r

system("\"C:\\Program Files\\R\\R-4.0.3\\bin\\R.exe\" -f code&.r")

but not with 3.6.3, and I would not be surprised if even more special 
characters became popular, soon.

After all, what if someone wanted to pass an argument to R including 
">", that should work, too:

---- t.r ----
cat("Header: ", commandArgs(TRUE)[1], "\n")
-------------

system("\"C:\\Program Files\\R\\R-4.0.3\\bin\\R.exe\" -f t.r --args 
<html>") # prints Header:? <html>
system("\"C:\\Program Files\\R\\R-3.6.3\\bin\\R.exe\" -f t.r --args 
<html>") # fails with? The syntax of the command is incorrect.

So in summary, I don't agree this is a bug.

Best
Tomas
On 1/29/21 11:19 AM, Duncan Murdoch wrote:
#
R/Rterm now has shell-independent ways to specify its standard input
file, --file=file.R, and environment variables, VAR=VALUE.  Should it
also have shell-independent arguments to specify files to contain
stdout and stderr or both?  Then its help message could omit the '>
output' (it can already leave out the '< infile').

The help message could then say that if those arguments are omitted
then Rterm uses stdin, stdout, and stderr.  Thus the user could come
up with the shell syntax if the user needed to use pipes or output
stream merging, etc.

-Bill
On Tue, Feb 2, 2021 at 5:49 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: