I have Windows 11, R version 4.2.1, RStudio version 2022.02.3 Build 492, although this problem existed with R 4.1.2 and and older version of RStudio as well, I updated in an attempt to fix it.
For one particular RStudio project (all other project have no problems), I can't open any scripts, and when I try, I get the error "The system cannot find the path specified". While the path is long, it is shorter than the windows file path character limit of 260 characters (it's 230).
This previous question seems similar but is a) more widespread and b) my issue is not fixed by running as administrator.
Additionally, the proposed solution does not seem to apply as my machine does not have a HOME variably in the system variables as described.
There are some other questions with the phrase "the system cannot find the path specified" but none of them seem directly applicable.
Additionally, I can open the script just fine in R or in notepad. It only fails to open in RStudio.
Related
When I double click an R script (.R file) in order to open and edit it, nothing happens.
I expect it to open it in either R or RStudio but it doesn't.
I found a similar (old) question (Opening a .R file via a double click (Windows)) but the solution doesn't work for me.
I have tried:
- right-clicking and explicitly telling it to open it with RStudio
- set it as the default program to associate with this file type
- drag the script into RStudio
Anyone any idea whether it is Windows or R(Studio) related?
Running:
Windows 10 Pro
R version 3.6.1
RStudio version 1.2.1335
As the first comment suggest, it is likely a problem occuring while installing R or Rstudio. This would most likely be fixed by reinstalling Rstudio. If it doesnt i'd suggest checking out this Rstudio question.
Basically, you can manually create using the command prompt (start -> "cmd" -> enter), using
assoc .R=rfile
Ftype rfile="C:\Program Files\RStudio\bin\rstudio.exe" %1
changing the rstudio directory to the correct directory for your computer.
A less command-prompty solution might be available by following the steps described in this guide. However i did not test the latter approach.
Attempting to use the mread function to open a cpp file through R. However, when I run the script I get the following:
setwd("C:/Users/Gustavo/Documents/R/page-2018-mrgsolve-master/model")
getwd()
#> [1] "C:/Users/Gustavo/Documents/R/page-2018-mrgsolve-master/model"
library(mrgsolve)
mod <- mread("simple", "model")
#> Error: project directory 'model' must exist and be readable.
Obviously I am setting the directory to "model" itself. So why isn't R able to read it? Any help would be appreciated as I am still learning R and want to learn the mrgsolve package as well.
Additional info: R version 3.4.4. Rtools version 3.4.0. Rstudio version 1.1.463.
An adaptation to the email I sent my colleagues that were assisting me with a similar issue:
To review, I was unable to open any files through RStudio because RStudio returned error messages indicating either that the file itself or the work directory did not exist. I've done multiple installations of different versions of R, RStudio, and Rtools in an attempt to resolve the issue. I also moved the locations of files and programs of interest and changed the work directory to see if that made a difference. Unfortunately, when RStudio is first initiated on a computer, it establishes a "hidden directory" folder that retains the settings of the program when it was first initiated. However, by deleting this folder, RStudio was wiped and I was able to regain control of where files would be stored and read as desired (more on this in the following link: https://support.rstudio.com/hc/en-us/articles/200534577-Resetting-RStudio-Desktop-s-State). A combination of this and forcing Rtools to the front of the 'path' also allowed me to resolve 'status 127' errors that I was receiving as well.
Unfortunately, this is the result of a more personal issue between the initial settings that RStudio took to my computer and my attempt to manipulate where RStudio should read files which I guess were discordant of one another? Regardless, it seems that I would need to be more cognizant of how RStudio establishes a folder which retains its initial settings.
I'm re-running some R Markdown scripts that worked fine a month ago, but now kable_as_image is unable to find Ghostscript (yes, I'm on Windows 8). I get the following error message:
Error in kable_as_image(criteria.table,"Criteria",file_format="jpeg"):
Ghostscript is required to read PDF on windows. Please download it here: https://ghostscript.com/
My computer still has Ghostscript, which runs fine when I open it up independently (I tried reinstalling Ghostscript; it didn't help). My guess is that the problem has something to do with R, RStudio, or a package being unable to find the Ghostscript.
I'm pretty sure I've upgraded R in the interim, and I'm currently on 3.4.3 with the latest versions of kableExtra and magick. I've also tried
Sys.setenv(R_GSCMD="C:/Program Files/gs/gs9.22/bin/gswin64.exe")
(and also for gswin64c.exe) but that didn't help, either. Any advice would be appreciated.
Despite what the error message says, R needs the path to MikTeX (or your TeX program of choice), not to Ghostscript itself. The best solution is to add it to PATH in your operating system directly so it's always there, but it also works to add it within R. This is helpful to test it out before digging into your OS (make sure you have the right path), or if you don't have administrator privileges to your work machine.
Sys.setenv("PATH"=sprintf("%s;C:\\Users\\me\\AppData\\Local\\Programs\\MiKTeX 2.9\\miktex\\bin\\x64\\",Sys.getenv("PATH")))
Your path to MikTeX will likely be different than mine. Note that you need sprintf() or something similar to add the directory to the end of the PATH instead of overwriting the existing path.
When running the checks for my R-package (via devtools::check()) I face the warning ''qpdf' is needed for checks on size reduction of PDFs. I found this question were it was suggested (if I understood the answer correctly) to run Sys.which(Sys.getenv("R_QPDF", "qpdf")) and see whether qpdf is found or not. In my case this just returns
qpdf
""
so, I think I didn't install qpdf correctly. Unfortunately it seems to be quite complicated to install qpdf on Windows. My first side question is: does it really is so painful and complicated to install qpdf for Windows or is there an easy solution?
I've followed the instructions until it is said to add C:\MinGW-w64\bin and C:\MinGW-w64\lib\mingw to the PATH variable. But then I don't find further specific instructions to install qpdf, only about how to build qpdf with different other programs. The second side question is: is my assumption correct that after I've build qpdf it is installed? But the real question is: What is the best way to build qpdf? I tried the ./config-mingw32 and ./config-mingw64 commands from the section "Building with MinGW" in my C:\MinGW\msys\1.0\bin\bash.exe but got the error messages ./config-mingw32: No such file or directory and have no idea how to fix this issue.
I'm using Windows 10, R version 3.3.2 Patched (2017-01-07 r71934) -- "Sincere Pumpkin Patch" and RStudio 1.0.136.
You basically do not need to build the file on windows. Please follow three steps below:
Download qpdf for windows from https://sourceforge.net/projects/qpdf/?source=typ_redirect
Extract files in a temp folder
Copy the contents of the bin folder to %SystemRoot%\System32
job done!
Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"C:\\WINDOWS\\SYSTEM32\\qpdf.exe"
To flesh out an answer provided elsewhere:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 10.0.1 is listed here).
Rather than copying files to C:/Windows/System32, a potentially safer option is to extracted the zipped qpdf directory to C:\Program Files. If you do this, you'll need to add C:\Program Files\qpdf-version_number\bin to your system PATH under the environment variables.
To do this within R, run Sys.setenv('PATH' = paste0('C:\Program Files\qpdf-version_numer\bin;', Sys.getenv('PATH')))
To do this in Windows, open the start menu, type "edit the system environment variables" to open the System Properties, and at the bottom of the "Advanced" tab click "Environment variables". Find the "Path" entry under "System variables" and click "Edit". Then, re-start R so it picks up the modified PATH.
One further step may be required to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning, as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. This done, Windows will recognize the file as safe to run and allow other software, including R, to use it.
I'm working with a software project that requires the portable version of R platform. My intention is to use R in any version of Windows and in any compatible computer.
Problem: In Windows 7, R works fine without any worries, even in portable version. However, in Windows 10 (and probably also in Windows 8), R does not start when put the entire folder inside a directory containing whitespaces (ex.: "C:/Users/Main/Documents/My Folder/RVersion").
In Windows 10, with the absence of spaces, R runs fine. In the presence of spaces, all executable (Rscript.exe, R.exe, etc) except Rgui.exe just open a console and closes instantly. The problem is: I really need that R works in any folder (this is a important part of the project).
Additional information:
I found that R does not work well in directories without the 8dot3 format - and it think that Windows 10 lost this property, which was present in Windows 7. Also, the problem is clear when I run Rgui.exe in a whitespace-containing directory and try to run system("R.exe", intern=TRUE) function: It throws an error indicating that only the part before the first space in directory name was taken into account. Here is the message:
> system("R.exe", intern=TRUE)
[1] "'C:\\Users\\Main\\DOCUME~1\\My' nÆo ‚ reconhecido como um comando interno"
[2] "ou externo, um programa oper vel ou um arquivo em lotes." attr(,"status")
[1] 1
Warning message:
running command 'R.exe' had status 1
Translation of messages [1] and [2]: "'C:\...\My'" not recognized as a internal or external command, nor a program operation or dataset
The same occurs with non-portable version of R, as I already tested.
When I run with a .bat file with the corrected (quoted) directory as input, R.exe runs, but in a disfunctional form and looking like cmd.exe (no R command worked).
I have no ideia how to change variables such as R_HOME to a readable version before R prompt starts.
System/Resources:
Windows 10 Home 64-bit with the last update.
Dell Notebook with Intel i7-5500U 2.40 GHz (not so relevant, I think)
R and R portable 3.3 (last version until this post), downloaded here:
[https://sourceforge.net/projects/rportable/]
I believe that, with the popularity of Windows 10, many other users could face this problem (specially those who depend of R portability).
Thanks in advance!
In the end, I found a plausible solution by myself.
I realized that every time the R.exe is executed in a directory without spaces, the execution is automatically redirected to Rterm.exe. I don't know if they fixed the bug specifically to Rterm.exe in the last version, but this suggests that the Rterm executable is the responsible for opening the R console, and when I tried to execute it directly through a spaces-containing directory, it worked fine (at least in the last R version).
So, in summary, if someone else had this problem, just run Rterm.exe directly.
This resolution is useful enough for those who just depend on R portability, although the Rscript.exe and R.exe still are not working in these conditions. Rscript.exe is useful to execute scripts directly without the need to manually start a new session in a new window, and R.exe redirects to Rterm.exe based on your system, if it is 32-bit or 64-bit (at least as I observed).
Anyway, I already informed CRAN project about this bug, and I hope they check it and fix the issue in the next version. If someone else found an alternative solution, feel free to comment.