I often find it more useful to run R on the command line (windows). However when I try it in Powershell I tend to run into problems, but this is easily overcome by first running cmd and then it works.
This is the error I get when I do R CMD BATCH
Invoke-History: A positional parameter cannot be found that accepts the argument 'BATCH'
I later realised that r is an alias that returns the immediate past command, hence my inability to run R.
Subsequently, I found that using the full filename for the executable (i.e. R.exe) or using Rcmd.exe (i.e. Rcmd BATCH ...) worked.
However, I'm just curious, is there a work around, in case one runs into similar conflicts?
To start R in powershell:
R.exe
The workaround would be fully defining your calls.
& "path\to the\r.exe" arg1 arg2 etc
Alternatively,
$P = #{
FilePath="path\to the\r.exe"
ArgumentList=#('arg1','arg2')
}
Start-Process #P
I ran into this problem on linux, where there is no file extension for executables, so that didn't help, but still there are two options:
/usr/bin/R if it is installed in the usual location
Start-Process R (the start-process cmdlet does not need to be capitalized)
Related
I'm trying to run an R script through the command prompt. My operating system is Windows 10. I'm having trouble running the code because there is a space in the file path of my argument. This is what I paste into the command prompt.
"C:\Program Files\R\R-3.4.3\bin\Rscript.exe" "C:\Users\Scott\Google Drive\RScriptsB\Bundle_Runner.R"
I get this error:
The filename, directory name, or volume label syntax is incorrect.
However, when I run it using a file path with no spaces, it runs fine.
"C:\Program Files\R\R-3.4.3\bin\Rscript.exe" "C:\Users\Scott\Desktop\Bundle_Runner.R"
The same behavior happens when I schedule the task through Task Scheduler: it doesn't work with the space, and it works when I remove the space from the file path.
I'm using Google Drive to sync work from multiple computers, so I'd like to be able to run my scripts using the file path with a space.
Any solutions?
FOR %%a IN ("C:\Users\Scott\Google Drive\RScriptsB\Bundle_Runner.R") DO "C:\Program Files\R\R-3.4.3\bin\Rscript.exe" %%~sa
would be my approach - the problem appears to be with R, not cmd.
Try this:
C:/PROGRA~1/R/R-3.4.3/bin/Rscript.exe "C:\Users\Scott\Desktop\Bundle_Runner.R"
Or
C:/PROGRA~1/R/R-3.4.3/bin/Rscript.exe C:/Users/Scott/Google~1/RScriptsB/Bundle_Runner.R
This is possibly related to an error reported at r-devel ("[Rd] Bug in RScript.exe for 3.5.0", https://stat.ethz.ch/pipermail/r-devel/2018-April/075869.html) that has been fixed the next day.
Perhaps the problem was already present in R 3.4.3 (you are using in your question).
Proposed workaround:
...add an extra first argument that has no space in it, e.g. Rscript --vanilla "foo bar.R"
To minimize the impact caused by --vanilla you could use
Rscript --no-save "foo bar.R"
instead (which just does not save the workspace at the end of the session).
I want to run a R script from matlab.
I can run the R code perfectly from cmd using:
cd "C:\Program Files\R\R-3.1.3\bin\x64"
R CMD BATCH "C:\Users\name\Desktop\Code.R"
However in Matlab I am not sure how to run this two instructions.
First, I noticed that I could use:
system('cd "C:\Program Files\R\R-3.1.3\bin\x64"')
to run a commnand line command. However I need to run two. And making:
system('cd "C:\Program Files\R\R-3.1.3\bin\x64"')
system('R CMD BATCH "C:\Users\name\Desktop\Code.R"')
does not work.
I also saw this post about running multiple command line instructions in a single line, but also that did not work.
Anyone knows how to do it?
Your script should generally not care where it’s executed. So you don’t need the cd statement at all:
system('"C:\Program Files\R\R-3.1.3\bin\x64\R.exe" CMD BATCH "C:\Users\name\Desktop\Code.R"')
Be careful thought that the R path might not always be the same … it’s probably safer to find R’s location programmatically. Though how to do that in Matlab on Windows, I don’t know.
Furthermore, I honestly don’t really know why R CMD BATCH even exists but I strongly recommend using RScript instead. It works much nicer for a number of reasons.
The code then becomes:
system('"C:\Program Files\R\R-3.1.3\bin\x64\Rscript.exe" "C:\Users\name\Desktop\Code.R"')
Try to use dos command instead of system.
The binary of Rscript is available but when I try to use it I get:
Rscript helloworld.r
Rscript execution error: No such file or directory
If I just do Rscript, it brings the help/usage for it through.
R CMD BATCH is working fine.
I tried adding shebang lines in the R code at the start but it didn't work.
#!/sys_apps_01/R/R-3.2.0/bin/R
#!/sys_apps_01/R/R-3.2.0/bin/Rscript
As in your case, this was caused by me moving R (in order to try to use it in an AWS lambda function).
I resorted to doing the equivalent call on R itself:
./R --slave --no-restore --file=TheScript.R
It's likely this was installed to (configured for) another directory and then moved after installation. Afterwards Rscript won't be able to find the (hardcoded?) R binary. I just had the same problem, which could be solved by reinstalling R.
Andreas
I preface this solution issuing a caution to do this at one's own risk. However I encountered the same issue and had the following solution:
Say you've run make && make install which has installed R to /path/to/install/loc. Once you've moved this to path/to/new/loc, R/Rscript will then complain it can't find the right file/directory.
Editing the R and Rscript executables in path/to/new/loc/bin, you can change any reference to /path/to/old/loc to /path/to/new/loc. This has worked for me and haven't encountered any further issues
As has been previously mentioned, it's definitely preferable to install R to the required location either through prefix=... in the configure script, or by using the rhome=... argument following make install
I encountered the same issue. What happened in my case was that, R was first installed at /usr/lib/R with deb packages, then I moved the dir to /opt/R and defined R_HOME to the new dir, hoping R will adapt to it automatically, but turns out there are hardcoded paths of /usr/lib/R in bin/R. Unless I update the paths, simply moving R to another location will break the installation.
How does R's built-in system() function know where to look to invoke some arbitrary OS command specified by the command argument? For example, if I homebrew install some_command_line_program, how does R's system() function know where it is located when I type:
cmd <- "some_complicated_code_from_some_command_line_program"
system(cmd, wait=FALSE)
In other words, how is R smart enough to know where to look without any user input? If I compile from source via Github (instead of homebrew install), would system() also recognize the command?
What system does depends on your OS, you've not told us (although you've given us some clues...).
On unix-alike systems, it executes it as a command in a bash shell, which searches for the first match in the directories on the $PATH environment variable. You can see what that is in R:
> Sys.getenv("PATH")
[1] "/usr/local/heroku/bin:/usr/local/heroku/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/nobackup/rowlings/NEST4B"
In Windows, it does something else.
You can get a full path to whatever it might run with Sys.which, which uses the systems' which command on unixes and fakes it on Windows. Read the help for more.
If you compile something from source then it will be found if the file that runs the command (a shell script, an executable, a #!-script in any language) is placed in a folder in your $PATH. You can create a folder yourself, say /home/user/bin, put your executables in there, add that to your $PATH, and (possibly after logging out an in again, or restarting R, or just firing up a new shell...) then R will find it.
Hej,
When I try to call QIIME with a system call from R, i.e
system2("macqiime")
R stops responding. It's no problem with other command line programs though.
can certain programs not be called from R via system2() ?
MacQIIME version:
MacQIIME 1.8.0-20140103
Sourcing MacQIIME environment variables...
This is the same as a normal terminal shell, except your default
python is DIFFERENT (/macqiime/bin/python) and there are other new
QIIME-related things in your PATH.
(note that I am primarily interested to call QIIME from R Markdown with engine = "sh" which fails, too. But I strongly suspect the problems are related)
In my experience, when you call Qiime from unix command line, it usually creates a virtual shell of it`s own to run its commands which is different from regular system commands like ls or mv. I suspect you may not be able to run Qiime from within R unless you emulate that same shell or configuration Qiime requires. I tried to run it from a python script and was not successful.