I get the following R code execution error when I try to export and download zipped files from the R Linux server to my computer even though I have the zip and unzip files installed.
Error in system(createZipCommand, intern = TRUE) :
error in running command
Have anyone come across something similar and how did you solve it?
many Thanks
RJ
I think I figured out what's going on here. It appears that the PATH definition (echo $PATH) got corrupted. This was also preventing me from installing and updating packages.
I updated the path-definition in the '.Renviron' file as below
PATH=/usr/lib64/ccache:/usr/lib/rstudio-server/bin/postback:/usr/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/puppetlabs/bin
Saved this new '.Reviron' file in the home folder, logged off from R Studio, and signed back in. Everything seems to be fine now.
I am trying to run a script to download some weather data from a NOAA ftp site.
When I attempt to run the following command:
system("wget ftp://ftp.ncdc.noaa.gov/pub/data/noaa/2016/999999-54856-2016.gz")
it returns status 127, which as I understand simply means the command will not run.
This link on the other hand, seems to be working well and downloads the zip folder when I ran it in the browser.
I read online about adding the path 'C:\Rtools\bin' from this link: Create zip file: error running command " " had status 127 but that doesn't seem to work either.
I'm wondering if this might be a permissions issue or other security setting preventing me from invoking system commands.
Any ideas?
Thanks!
You're using Windows. wget is a Unix/Linux program. You can just call download.file to download from within R:
download.file("ftp://ftp.ncdc.noaa.gov/pub/data/noaa/2016/999999-54856-2016.gz",
"999999-54856-2016.gz", mode="wb")
The mode="wb" is important for downloading binary files 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
I have s script that produces a lot of small PNG files that I want to remove when I close my gWidgets interface. I thought I could do that in Windows using
shell( "del *.png" )
but neither in the script nor in interactive mode in R (2.15.2), this has any effect at all (not even an error or warning). Probably I'm doing something wrong but I can't find out so far what.
Has somebody an idea for me?
I've just tested your command -- same version of R on Windows XP -- and it works exactly as you would expect. If this command is not working for you, I strongly suspect that R's working directory may be different from the directory in which you have your .png files.
You could try:
shell('dir *.png')
... to verify that the .png files are, in fact, in the current working directory before trying to delete them. If they are not there, you will get the report:
File Not Found
Warning messages:
1: running command 'C:\WINDOWS\system32\cmd.exe /c dir *.png' had status 1
2: In shell("dir *.png") : 'dir *.png' execution failed with error code 1
Also, if you've run the del command once, so there are no .png files remaining in the directory, the second time that you run that command you should get an error message like the following:
> shell("del *.png")
Could Not Find C:\usr\sjl\dev\test\R\*.png
I am using R 2.13.0 with windows 7, after giving my user full privileges to the R folder (as described here).
This allows me to install new packages just fine.
However, when using update.packages(), to update existing packages, I keep getting the following error (for example, when updating the MASS package):
package 'MASS' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation
'C:\Program
Files\R\R-2.13.0\library\file6cae3bcf\MASS'
to 'C:\Program
Files\R\R-2.13.0\library\MASS'
Any suggestions on how to fix this?
p.s: Running R as an administrator or shifting the library location out of Program Files is not a solution (it's a hack - but I am looking for a solution)
I found that the problem indeed is the antivirus "real time file system protection". I do the following to fix the problem:
trace(utils:::unpackPkgZip, edit=TRUE)
I edit line 140 (line 142 in R 3.4.4):
Sys.sleep(0.5)
to:
Sys.sleep(2)
I seems like the antivirus stalls the creation of the package tmp dir. After changing it to 2 seconds the error is gone.
EDIT: to do this programmatically execute
trace(utils:::unpackPkgZip, quote(Sys.sleep(2)), at = which(grepl("Sys.sleep", body(utils:::unpackPkgZip), fixed = TRUE)))
(credits #DavidArenburg)
Just to update everyone, I (think that I) found out the source of the problem: antivirus.
The "real time file system protection" was blocking R from copying the files between folders once they were downloaded.
Upon adding the R directory to the exception list (coupled with adding user permission and installing R on D:\R), and the problem went away. With all of this work, I might as well switch to Linux (I should, really...)
(I updated my post with the above information: http://www.r-statistics.com/2011/04/how-to-upgrade-r-on-windows-7/)
I hope it will help someone in the future,
Tal
If you cannot turn off your antivirus, due to corporate policy for example, here is a workaround that I found. Debugging the unzip package function and then stepping through it gives the antivirus enough time to do its job without interfering. Use this command:
debug(utils:::unpackPkgZip)
install.packages("packageName")
and then step through the code (by pressing enter many times) when R starts debugging during the installation.
I found this solution here.
If you can just download the binary straight from CRAN. On windows when downloaded it will be a zip file. Now manually unzip this into the ..library/ folder of your R (.libPaths()). It worked for me on some packages.
I had this problem installing both swirl and dplyr. I am working on Windows 64-bit.
Warning: unable to move temporary installation
What I did is I accessed my temporary files on the C: drive, and opened my file extractor program and I extracted the files from the temp file in the C: drive to my R program files in the C: drive, by manually copying them. THIS WORKED FOR BOTH dpylr and swirl. Stoked!
Cheers,
Peach
Can you not use the lib.loc parameter to only update packages in your personal library (in user)?
There should be no way to enable a normal, non-augmented user to change files in the program files folder, so the only thing you can do (if you don't want to augment the user) is to have R not updating packages there.
A workaround is to avoid installing R in the program files folder (which may be more or less of a hack than just shifting the library location out of it, depending on your point of view).
Finally, if lib.loc doesn't cut it, you can look at the source code for update.packages and create your own customized version that will always avoid the common library location in program files.
I just met the same question, and the solution I found out was that you should install packages using the original R software (plus, you should choose the right mirror site, some of them are blocked). At first I used Rstudio to install packages and I got the same problem as you met. Hope this is helpful.
I have run into this error several times. In my own case, it is because our admins want us to use remote virtual disks (on Windows 7) for our files and everything is locked up tight as a drum. The only way I can use R packages is in a lib directory on that remote virtual disk. This wouldn't be a problem except that the network isn't always smooth and fast. Thus, when I need a package, especially one with several other packages in tow (e.g., MBESS), I either have to go through the get.packages() process multiple times until it finally finishes or make it IT's headache to do quick like the bunny for me. I can't always wait for IT.
I just went to the library folder (Windows XP) and deleted all fileXXXX folders. Reran the install an it is worked.
I had the same problem. Since the issue seems to be the antivirus blocking the transf of a downloaded file, I tried a different download method in the install.packages and it worked.
For example:
install.packages("stringr", method = "curl")
You must go into the properties of the R folder and change the security parameters. You can enable the option to write and modify for all users.
The error : "unable to move temporary installation" is basically arising due to any of the antivirus running on your system.
Try unzipping the downloaded file from the Temp folder into the default library path (you can get it by running .libPaths() in R session).
I'm using a MRAN and I was having so many versioning issues. Trying to work with tidyverse and ggplot2 and by upgrading to the latest version from Microsoft it solved all of my R-Studio versioning issues.
Version info:
Microsoft R Open 3.5.1
The enhanced R distribution from Microsoft
Default CRAN mirror snapshot taken on 2018-08-01.
Download Microsoft R Open 3.5.1