R system2 trouble invoking R script on windows - r

I frequently use RODBC to connect with Microsoft Access databases and can only do this in 32-bit R because 32 bit MS Office is loaded on my Windows 7 PC.
After extracting my data from an MS access database in 32-bit R, I usually then want to manipulate and analyse it in 64-bit R. In addition I am trying to write a script that others may need to use and I would like to simplify things by invoking 32-bit R inside RStudio (which I have set up to use 64-bit R, version 3.1.2).
I found this post which seemed to be just what I was looking for and attempted to run the suggested code. However, this gives me a fatal error indicating that my working directory does not exist, even though I have been working from this directory within 64 bit R and 32 bit R with and without RStudio and have never had any problems:
> system2("C:\\Users\\Joe.Bloggs\\Documents\\R\\R-3.1.2\\bin\\i386\\Rscript.exe", normalizePath("my script.R", winslash = "\\", mustWork = TRUE), invisible=FALSE)
Fatal error: cannot open file 'H:\03.': No such file or directory
Warning message:
running command '"C:\Users\Joe.Bloggs\Documents\R\R-3.1.2\bin\i386\Rscript.exe" H:\03. B Project\my script.R' had status 2
Note that I have installed R and RStudio in the "Documents" folder in the C drive since I don't have administrative rights.
Also, my R script is on a network drive (H).
I have tried copying the R script I want to run to the default working directory of 32-bit R on my C drive and explicitly stating the filepath to it without using normalizePath (as I assume this command expands to my current working directory in 64-bit R), but this gives the same error as above.
Further, if I just try to invoke 32-bit R, I get a warning:
> system2("C:\\Users\\Joe.Bloggs\\Documents\\R\\R-3.1.2\\bin\\i386\\Rscript.exe", invisible=FALSE)
Usage: /path/to/Rscript [--options] [-e expr [-e expr2 ...] | file] [args]
--options accepted are
--help Print usage and exit
--version Print version and exit
--verbose Print information on progress
--default-packages=list
Where 'list' is a comma-separated set
of package names, or 'NULL'
or options to R, in addition to --slave --no-restore, such as
--save Do save workspace at the end of the session
--no-environ Don't read the site and user environment files
--no-site-file Don't read the site-wide Rprofile
--no-init-file Don't read the user R profile
--restore Do restore previously saved objects at startup
--vanilla Combine --no-save, --no-restore, --no-site-file
--no-init-file and --no-environ
'file' may contain spaces but not shell metacharacters
Expressions (one or more '-e <expr>') may be used *instead* of 'file'
See also ?Rscript from within R
Warning message:
running command '"C:\Users\Joe.Bloggs\Documents\R\R-3.1.2\bin\i386\Rscript.exe"' had status 1
Any insights into what I am doing wrong would be much appreciated; I tried using single forward slashes instead of double back slashes in both file paths but to no avail; I still got the same error.
How can I get system2 to locate my R script and run it in 32-bit R?
Also is there a resource that explains what the status numbers in the warnings mean?
Many thanks for your help.

I've been trying to do the same thing (call 32 bit R from 64bit RStudio for RODBC) and asked a similar question here. I used a slightly different approach and did:
system(paste0(Sys.getenv("R_HOME"), "/bin/i386/RScript.exe H:\\path\\to\\file.R"), wait = FALSE, invisible = FALSE)

Related

Find pandoc executable from R

rmarkdown::find_pandoc helps us to find the pandoc executable w/o the need of specifiying any environmental variable when running form within RStudio:
## in Rstudio
!is.null(rmarkdown::find_pandoc()$dir)
# [1] TRUE
However, when running the same command from a plain R console I get:
### R console
!is.null(rmarkdown::find_pandoc()$dir)
# [1] FALSE
Reading the documentation pf ?rmarkdown::find_pandoc(), explains why I am getting these results:
dir: A character vector of potential directory paths under which
‘pandoc’ may be found. If not provided, this function
searches for ‘pandoc’ from the environment variable
RSTUDIO_PANDOC (the RStudio IDE will set this variable to the
directory of Pandoc bundled with the IDE), the environment
variable PATH, and the directory ‘~/opt/pandoc/’.
I want now to write a script which can be run from the command line (specifically not from within RStudio), which needs pandoc to be found. As per the help I could set my PATH to assure that pandoc is also found from the command line, but as soon as I want a colleague of mine to use the script, I have to make sure that his/her PATH is set accordingly and I want to avoid that.
However, I do know that everybody has Rstudio installed (not at the same location though), so if I knew the location of RStudio I could derive pandoc's location too.
Is there any reliable way to get the path of Rstudio from the console (i.e. also when Rstudio is not running)?
To make a long story short: how can I find Rstudio even if it is not running`?
This could work, it is based on linux, but I guess if you are in other system, it could be adapted:
pandoc_path <- system2("find", args="/usr/lib/rstudio -name pandoc -type f", stdout = T)
path_sep <- ":"
Sys.setenv(PATH = paste0(Sys.getenv("PATH"),path_sep, sub(".pandoc$","",pandoc_path )))

Cannot run interactive R session from the command line - windows 10

I cannot run a R session from the command line by typing 'R', despite having
C:/Program Files/R
and
C:/Program Files/R/R-3.3.2/bin
in both 'Path' (System) and 'PATH' (User) environment variables (the latter directory is where the actual application is located, I was just trying everything by adding the former).
If I manually change the working directory to C:/Program Files/R/R-3.3.2/bin and type R, a session runs.
Any insight as to why this might be the case? Other programs such as Python 3 run fine, provided the the environment variable is set, why not with R?
This question is part of a larger problem where I am trying to get rpy2 working, but though successfully installed, none of it's basic functions are working, and I thought this maybe to do with a version of R being installed at C:/Users/Anaconda2/R (Because this dir was in Path). The R application installed here would not work when opened, but was the directory returned when I typed R RHOME into cmd - despite the fact this installation is not even functioning, and has apparently only existed since I installed rpy2 a couple of hours ago. I reasoned that rpy2 is trying to use the instance of R installed here rather than my normal one, thus causing the error when I call robjects.r. But this still doesn't explain why I can't run R from cmd. When using R.home(component = "home") from inside a an R session (in RStudio or out of it), it returns my normal, working R directory, at C:/PROGRA~1/R/R-33~1.2. By moving the R file tree installed in Anaconda's directory to a somewhere not in Path, I hoped Windows would find the correct installation via Path - but instead I just get Failed to create process.
My last guess was that Windows didn't like the space in "Program Files", but loads of variables in Path go through the same folder. Any ideas?
I am using:
Windows 10,
R 3.3.2,
Python 2.17.13
UPDATE, PERHAPS SOLVED:
On Josh O'Brien's recommendation (thanks!), I typed where R into cmd, returning:
C:\Users\charl\Anaconda2\Scripts\R.exe
C:\Program Files\R\R-3.3.2\bin\R.exe
The first path is marginally different from the C:\Users\charl\Anaconda2\R listed in my first post (both are in Path), and leads to a third R.exe. It's outside the R file tree located in Anaconda, unlike my standard R installation, but seems to be dependent on it nonetheless. If I remove this R.exe to another location (not in Path), Typing R in cmd will run R from the desired directory, thus fixing the problem. R.home() from inside that session confirms this.
My only remaining concern then; is whether this installation of R in Anaconda necessary for rpy2 or can I just delete it, fixing the original problem? It may just be my ignorance, but I was not conscious that installing rpy2 (I used the standard Windows installer rather than compiling manually) would install another instance of R - is it necessary for the package or just a default/option I failed to omit?

running .exe from R: status 127 warning on Linux not on Windows

I'm calling an .exe from R using system("script.exe object").
I get Warning: running command had status 127. I know it means the .exe file has not been found.
I'm on windows. When I use shell instead of system it works like a charm. However, I am designing a Shiny application that will be deployed in a Linux environment (shinyapps.io). This is why I need to use system.
EDIT
On Windows, it works with system(paste("cmd.exe /c", "script.exe object"), intern = FALSE, wait = TRUE) as suggested here. But not when I deploy the app (on Linux).
HINT
Locally on Windows, if I replace system with system2: system2(paste("cmd.exe /c", "script.exe object"), wait = TRUE), it raises the status 127 warning and the output is exactly the same as in my deployed app on Linux.
It's tough to create a reproducible example here but if needed I can try. Please tell me.
Context: basically the .exe is a black box (compiled C++ code) that takes a .txt file as input and outputs another .txt file. I am using R to dump the .txt file to the current working directory, then read back in the .txt file generated by the .exe (created in the current working directory, where the .exe file is stored).
Just add \" could solve you problem, e.g.
> setwd("W:/www/ADemo/")
> system(paste0(getwd(),"/Hi 2.exe"))
Hello, world.
> setwd("W:/www/A Demo/")
> system(paste0(getwd(),"/Hi 2.exe"))
Warning message:
running command 'W:/www/A Demo/Hi 2.exe' had status 127
> system(paste0("\"",getwd(),"/Hi 2.exe","\" "))
Hello, world.
Update:
The 127 error is usually seen when there is a space in the path. One also needs to worry about the input of the application, e.g. "/path A/A 2" --in-path "/home/A/B C/d 123.dta". Here are some update comments:
system(shQuote(paste0(getwd(),"/Hi 2.exe"))) is much more convenient.
At least in R 3.2.4, the manual of system() recommends to use system2() instead to avoid path problem under Win/Linux/OSX/.
Update 2:
For Linux user, I created a function to detect the given file in your working directory is executable or not:
chkpermission<-function(file, mode='0777'){
exe_list <- system("echo `ls -l | grep -E ^-.{2}x\\|^-.{5}x\\|^-.{8}x` | awk '{print $9}'", intern=T)
if(length(exe_list)==0){
stop("no file is executable");
##Make sure you know what you are doing here, add a+x permission:
## if (!(file%in%exe_list)) Sys.chmod(file, mode = mode)
}
return(file%in%exe_list);
}
I've tested it on GNU awk/grep. The 2/5/8 indicates the executable permission of [u/2]ser, [g/5]roup, [o/8]thers., one could change it to meet the requirement.
The problem actually stemmed from the fact that .exe files are executables for Windows only. It does not work out of the box on Linux environments (you can use WINE but in my case it is not possible because I am calling the executable from within R, I don't have any sudo rights or anything on the virtual machine used by the host of my app). So I compiled the c++ code I had using g++ on a Linux virtual machine and used the .out file rather than the .exe.
Then in my R script I just needed these two calls:
system("chmod a+x script.out") # to make Linux understand that the file is an executable
system("./script.out object") # to run the script

Command to see 'R' path that RStudio is using

Original Question
This seems easy and has likely been asked before, but I could not find it via a search.
I have a few flavors of R installed. I simply want to know, when I run RStudio, which flavor of R is it pointing to. So, I need a command -- within RStudio itself, ideally -- that can tell me the underlying R executable that is being used for this RStudio window that I am currently working with.
To be clear, I do not need / want to know the version of R that I'm using (e.g., R version 3.2.2 (2015-08-14) -- 'Fire Safety'). Instead, I want to know the actual path that RStudio is using to get to R -- looking at it from within RStudio -- so that I know "for reals" which version it's using. (E.g., /usr/local/bin/R.)
Edit & Answer
There are a lot of great discussions here, and some are OS-specific. I have a Mac. In my case, I found that:
> system("type R")
R is /usr/local/bin/R
> R.home()
[1] "/usr/local/Cellar/r/3.2.2_1/R.framework/Resources"
> file.path(R.home("bin"), "R")
[1] "/usr/local/Cellar/r/3.2.2_1/R.framework/Resources/bin/R"
As those of you familiar can see, I am using brew. If I look for /usr/local/bin/R outside of R, I see:
$ ls -l /usr/local/bin/R
lrwxr-xr-x 1 mike admin 25 Nov 14 17:31 /usr/local/bin/R -> ../Cellar/r/3.2.2_1/bin/R
which eventually resolves (2 symbolic links) to:
/usr/local/Cellar/r/3.2.2_1/R.framework/Resources/bin/R
as the final destination.
So on my system (Mac OS X), file.path(R.home("bin"), "R") was the most accurate.
(Edited to reflect fact that this is apparently a Windows-specific solution.)
Here on Windows, I'd use the following, for reasons discussed here by Henrik Bengtsson near the start of a long thread on the subject.
file.path(R.home("bin"), "R")
This is better than using file.path(R.home(), "bin", "R") in several settings alluded to in the "Value" section of this snippet from help(R.home):
Details:
The R home directory is the top-level directory of the R
installation being run.
[...]
Value:
A character string giving the R home directory or path to a
particular component. Normally the components are all subdirectories
of the R home directory, but this may not be the case in a Unix-like
installation. [...] The return value for "modules" and on Windows
"bin" is to a sub-architecture-specific location.

Rscript: There is no package called ...?

I want to run R files in batch mode using Rscript, however it does not seem to be loading the libraries that I need. The specific error I am getting is:
Error in library(timeSeries) : there is no package called 'timeSeries'
Execution halted
However I do have the package timeSeries and can load it from Rstudio, RGui, and R from the command line no problem. The issue seems to only be when running a script using Rscript.
My system/environment variables are configured as:
C:\Program Files\R\R-3.1.0\bin\x64 (Appended to PATH)
R_HOME = C:\Program Files\R\R-3.1.0
R_User = Patrick
I am running the same version of R in RStudio, RGui, and R from command line. I've also checked .Library from these three sources and got the same output as well.
How can I run Rscript from command line with the packages that I am using (and have installed) in R?
EDIT:
I am using Rscript via Rscript script.r at the windows command line in the directory where script.r is located.
The output of Rscript -e print(.Library) is [1] "C:/PROGRA~1/R/R-31~1.0/library"
which is consistent with the other three options that I mentioned: [1] "C:/PROGRA~1/R/R-31~1.0/library"
However, if I put this in my script:
print(.libPaths())
library(timeSeries) #This is the package that failed to load
I get an output of:
[1] "C:/Program Files/R/R-3.1.0/library"
Error in library(timeSeries) : there is no package called 'timeSeries'
Execution halted
The corresponding call in RStudio gives an additional path to where the package is actually installed:
> print(.libPaths())
[1] "C:/Users/Patrick/Documents/R/win-library/3.1" "C:/Program Files/R/R-3.1.0/library"
In short, the value returned by calling Sys.getenv('R_LIBS_USER') in R.exe needs to be the same as the value returned by calling this at the command line:
Rscript.exe -e "Sys.getenv('R_LIBS_USER')"
and the above value needs to be included in this command line call:
Rscript.exe -e ".libPaths()"
Note that the values of R_LIBS_USER may be differ between R.exe and Rscript.exe if the value of R_USER is changed, either in the .Rprofile or the in target field of user's shortcut to R.exe, and in general, I find that the user library (i.e. .libPaths()[2]) is simply not set in Rscript.exe
Since I'm fond of setting R_USER to my USERPROFILE, I include the following block in at the top of .R files that I wish to run on mulitiple computers or in Rscript.exe's .Rprofile (i.e. Rscript -e "path.expand('~/.Rprofile')"):
# =====================================================================
# For compatibility with Rscript.exe:
# =====================================================================
if(length(.libPaths()) == 1){
# We're in Rscript.exe
possible_lib_paths <- file.path(Sys.getenv(c('USERPROFILE','R_USER')),
"R","win-library",
paste(R.version$major,
substr(R.version$minor,1,1),
sep='.'))
indx <- which(file.exists(possible_lib_paths))
if(length(indx)){
.libPaths(possible_lib_paths[indx[1]])
}
# CLEAN UP
rm(indx,possible_lib_paths)
}
# =====================================================================
As mentioned in the comments, it seems Rscript doesn't recognize the library path defaults automatically. I am writing an R script that needs to be source-able from the command line on different people's computers, so I came up with this more general workaround:
First store the default library path in a variable (Rscript-sourced functions can find this, they just don't automatiocally)
Then include that path in the library() call with lib.loc = argument.
This should work regardless of what the path is on a given computer.
library.path <- .libPaths()
library("timeseries", lib.loc = library.path)
Thanks again to #flodel above for putting me on the right path
This answer will not help the original asker (pbreach), but it may help someone else who stumbles across this question and has a similar problem to me.
I have many bash .sh script files which call RScript to execute .R files. My operating system is Windows 10, and I execute those bash files using cygwin.
Everything had been working fine until yesterday, when I finally upgraded my R from Revolution R 8.0.1 beta to Microsoft R Open 3.4.1. After that upgrade, every bash script that called RScript failed due to the exact same reason asked here (e.g. Error in library(zoo) : there is no package called 'zoo').
Investigation revealed that RScript actually worked fine if called from a DOS shell instead of from a cygwin bash shell.
For example, if I execute this in a DOS shell
C:\Progra~1\Microsoft\ROpen~1\R-3.4.1\bin\x64\Rscript.exe -e ".libPaths()"
I see the output
[1] "C:/Users/HaroldFinch/Documents/R/win-library/3.4"
[2] "C:/Program Files/Microsoft/R Open/R-3.4.1/library"
I eventually discovered the reason. As explained in the R FAQ, to define its home directory, R will first use the R_USER environment variable if defined, else it will use HOME environment variable if defined, else it will use the Windows "personal" directory.
My Windows configuration does not define either R_USER or HOME environment variables. So, in the DOS shell case, R uses my Windows "personal" directory (C:/Users/HaroldFinch/Documents). That is good, because that is where all my libraries are installed (C:/Users/HaroldFinch/Documents/R/win-library/3.4).
In contrast, cygwin defines and exports a HOME environment variable that points to my cygwin user directory, which lacks any R stuff. Hence, RScript called from cygwin had a wrong R home directory, and so failed to load libraries.
There are probably many ways to solve this. I decided to have my bash script set a R_USER environment variable which points to my Windows user directory.
For example, if I execute this in a cygwin bash shell:
R_USER="C:/Users/HaroldFinch/Documents"
export R_USER
/cygdrive/c/Progra~1/Microsoft/ROpen~1/R-3.4.1/bin/x64/Rscript.exe -e ".libPaths()"
I see the output
[1] "C:/Users/HaroldFinch/Documents/R/win-library/3.4"
[2] "C:/Program Files/Microsoft/R Open/R-3.4.1/library"
which is exactly the same output now as the DOS shell example above.
Another cause is packrat. If you are running with packrat, RStudio turns it on for you when you open the project. RScript does not, so you need a packrat::on() early in your script (before the library calls).
As the others have already pointed out, the problem is that Rscript.exe cannot recognise the win-library folder. The easiest solution for me was to explicitly set the path to the library folder by adding:
.libPaths("C:/Users/Benutzer1/Documents/R/win-library/4.0")
to my program. Then it loads all the packages from the win-library folder and it is still capable of loading packages from the standard library folder.

Resources