-
Notifications
You must be signed in to change notification settings - Fork 759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C:\Program is not recognized as internal or external program #1514
Comments
Hm, I wonder if this is the root cause of #885. We tried getting to the bottom of it but never figured it out. |
Looks like it to me |
@pfgherardini was this with the GitHub version of |
(I'm the one with the original problem who @pfgherardini was helping out.) @gaborcsardi the version of devtools in the master branch of this repo has the same problem. I think this is worth filing as a bug in R-core, as newer versions of Windows have SFN disabled by default on NTFS drives other than |
Thanks! |
Hello guys! [Editing my previous reply] I had posted a long reply arguing that enabling 8dot3name wouldn't work, but I was wrong. I took the time to investigate further and simply enabling it using What are our options then? I thought about creating shortnames for C:\Program Files, would it solve it? Or would it be needed for other folders as well? Anyway, it doesn't seem straightforward, specially for the average user (look here). I'm asking all of this instead of testing bc I have this issue with my employer's computer, what leaves little room to experiment (security concerns from the IT guys, a lot of convincing to do, spending precious work hours because I can't do it from home ...). My home PC has 8dotname enabled and it works fine (maps C:\PROGRA~1 to C:\Program Files as it should). That said, is this being addressed elsewhere (e.g. R-core)? I couldn't find a reply for the issue on the R-devel threads (@hadley's question here). Thanks again everyone! Abraço, My original post is below: I've had the same issue, specifically when trying to create a binary for a package I use at my work ( Long story short: enabling the 8dot3name didn't seem to help, but I may be having some issues with Rtools as well. More below. Trying to build the binary (.zip, for windows), I get: "C:/Program Files/R/R-3.4.0patched/bin/x64/R" --no-site-file --no-environ \
--no-save --no-restore --quiet CMD INSTALL "D:\_PACOTES R\utilidades" \
--build --preclean
'C:\Program' n�o � reconhecido como um comando interno
ou externo, um programa oper�vel ou um arquivo em lotes.
Error: Command failed (1)
Execution halted
Exited with status 1. (which is this thread's title in Portuguese with a few encoding issues) If I try to Build & Reload, I get: ==> Rcmd.exe INSTALL --no-multiarch --with-keep.source utilidades
'C:\Program' n�o � reconhecido como um comando interno
ou externo, um programa oper�vel ou um arquivo em lotes.
Exited with status 1. It also brings a popup: Building R packages requires installation of additional build tools. Do you want to install the additional build tools now?. By clicking 'yes' it tries to download Rtools, which I already have, but fails because the mirror it uses is blocked by the IT department. I don't think this is at the core of the issue, since it fails the build as usual ("C:\Program is not recognized as internal or external program..."). On issue #855 Hadley said the
In my case, it is still returning the full path: > R.home()
[1] "C:/Program Files/R/R-3.4.0patched" Additionally, for
In my case, enabling 8dot3name didn't change it either: > shortPathName(R.home())
[1] "C:\\Program Files\\R\\R-3.4.0patched" I couldn't find a reply for the issue on the R-devel threads (Hadley's question here). Question: is this being addressed elsewhere (e.g. base R)? > sessionInfo()
R version 3.4.0 Patched (2017-06-17 r72808)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)
Matrix products: default
locale:
[1] LC_COLLATE=Portuguese_Brazil.1252 LC_CTYPE=Portuguese_Brazil.1252 LC_MONETARY=Portuguese_Brazil.1252
[4] LC_NUMERIC=C LC_TIME=Portuguese_Brazil.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.0 tools_3.4.0 Abraços, |
I am also having this issue right now. @zbjornson I believe you may be onto something-- is it possible this is an issue if the "Program Files" directory is located on a second hard drive separate from the Windows OS? I have the majority of my files on a D drive. Note the below output is trying installation with a local download of the github repo after failing with the devtools::install_github command.
|
Running Try uninstalling and reinstalling R, this time into a brand-new directory tree (not under |
@Hong-Revo Of course, that worked. Doesn't solve the core issue, but thank you for the help. |
I reported this issue on r-devel last week: https://stat.ethz.ch/pipermail/r-devel/2017-September/074921.html The R developers keep bugzilla locked down, so I can't file a bug directly, and no one has picked up the bug from the mailing list yet. |
@zbjornson thanks for the update. |
https://stat.ethz.ch/pipermail/r-devel/2017-October/075023.html
|
Great. Here's the relevant commit: wch/r-source@4fc4867 |
I just ran into the same issue, following Hadley's instructions on how to "make" the ggplot2 book.
So doing some research I found this thread and it seems (?!?) the issue is resolved. But since I have no experience with git at all, I still have no clue how to resolve it in my case and would be very happy if someone could guide me through it (step by step for newbies) Edit: Now I tried it using the Git Bash and learned that the make command Hadley suggests is not part of normal Git but needs to be installed as an "add on". So I did that and everything works fine, except for the final command "make" (make clear worked fine!). $ make |
Is this still broken?
|
I still have the same problem
…On Thursday, June 28, 2018 2:46:42 AM EDT Michael Batech wrote:
Is this still broken?
`> install.packages("finalfit")
installing the source package ‘finalfit’
trying URL
'https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.rstudio.com_src_
contrib_finalfit-5F0.7.8.tar.gz&d=DwIFaQ&c=c6MrceVCY5m5A_KAUkrdoA&r=ONEg04Ap
1V9ObWqAi-6ivIsrgcd91QLmkEy8RAKCfoM&m=wlWFJXFfmObHL7u13uti01GpV3Qon2A910Lpmv
ACCak&s=dWYPni3Fyzp8sJ3QeiLIVAz52YWLHO5si8eS6TwUJfs&e=' Content type
'application/x-gzip' length 922694 bytes (901 KB)
downloaded 901 KB
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
Warning in install.packages :
running command '"C:/Program Files (x86)/R/R-3.4.2/bin/x64/R" CMD INSTALL
-l "C:\Program Files (x86)\R\R-3.4.2\library"
C:\Users\M285595\AppData\Local\Temp\Rtmpa8EnDU/downloaded_packages/finalfit
_0.7.8.tar.gz' had status 1 Warning in install.packages :
installation of package ‘finalfit’ had non-zero exit status
The downloaded source packages are in
‘C:\Users\M257495\AppData\Local\Temp\Rtmpa8EnDU\downloaded_packages’
> R.home()
[1] "C:/Program Files (x86)/R/R-3.4.2"
> shortPathName(R.home())
[1] "C:\\Program Files (x86)\\R\\R-3.4.2"`
|
@Ruminare Upgrading to the latest version of R (3.5.0) might help. |
This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/ |
Hi All,
I realize this is probably a bug in R-core, but I figured maybe a workaround can be implemented in devtools, since it shows up because of the way R is invoked from this package.
Basically on Windows, depending on system configuration,
install_github
fails with a message similar toC:\Program is not recognized as internal or external program
This happens when both of the following conditions are met
The second point can be verified with this command (assuming R is installed on the C drive; requires admin privileges, more info here)
fsutil.exe behavior query disable8dot3 C:
if the output looks like
8dot3 name creation is disabled on C:
then you are in trouble because R will not be able to handle a path with spaces properly, AND it will not be able to get an SFN-style path because it's disabled on your volume.
A telltale sign of this problem is that you won't be able to start
R.exe
from the command line, even though the RGui will start fine. This does not create a problem for the built-ininstall.packages
function because it does not spawn another R process likedevtools
seems to do.The text was updated successfully, but these errors were encountered: