C:\Program is not recognized as internal or external program

[pfgherardini]

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 to
C:\Program is not recognized as internal or external program

This happens when both of the following conditions are met

• R is installed in a directory that contains whitespace in its name (e.g. "Program Files")
• Short filenames (SFN) are disabled for the volume on which R is installed

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-in install.packages function because it does not spawn another R process like devtools seems to do.

[wch]

Hm, I wonder if this is the root cause of #885. We tried getting to the bottom of it but never figured it out.

[pfgherardini]

Looks like it to me

[gaborcsardi]

@pfgherardini was this with the GitHub version of devtools? If not, can you please try it with the GitHub version? Thanks.

[zbjornson]

(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 C: AFAIK. That is, the issue will only get worse as more users get newer versions of Windows.

[gaborcsardi]

Thanks!

[raonirao]

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 fsutil.exe doesn't create shortnames for existing diretories (such as C:\Program Files). So the problem hasn't been solved for my R installation's folder.

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,
Raoni

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 (devtools::build). I've talked with the IT department and they've enabled the 8dot3name to all volumes in my machine (currently 2, the R is on C:)

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 R.home() is supposed to return the 8.3 name. From ?R.home():

On Windows the values of R.home() and R_HOME are switched to the 8.3 short form of path elements if required and if the Windows service to do that is enabled. The value of R_HOME is set to use forward slashes (since many package maintainers pass it unquoted to shells, for example in ‘Makefile’s).

In my case, it is still returning the full path:

> R.home()
[1] "C:/Program Files/R/R-3.4.0patched"

Additionally, for utils::shortPathName's documentation:

For most file systems, the short form is the ‘DOS’ form with 8+3 path components and no spaces, and this used to be guaranteed. But some file systems on recent versions of Windows do not have short path names when the long-name path will be returned instead.

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,
Raoni

[julcoh]

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.

> devtools::install_local("D:/Downloads/streamgraph-master")
Installing streamgraph
"D:/Program Files/R/R-3.4.1/bin/x64/R" --no-site-file --no-environ --no-save --no-restore --quiet CMD INSTALL  \
  "C:/Users/Julien/AppData/Local/Temp/Rtmpuw4ku3/file25583e4523d5/streamgraph-master" --library="D:/Program  \
  Files/R/R-3.4.1/library" --install-tests 

'D:\Program' is not recognized as an internal or external command,
operable program or batch file.
Installation failed: Command failed (1)

[hongooi73]

Running fsutil.exe enables short filename support for a drive, but doesn't create them for directories that already exist.

Try uninstalling and reinstalling R, this time into a brand-new directory tree (not under \Program Files). Or you could delete \Program Files and recreate it, but I really wouldn't do that.

[julcoh]

@Hong-Revo Of course, that worked.

Doesn't solve the core issue, but thank you for the help.

[zbjornson]

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.

[julcoh]

@zbjornson thanks for the update.

[zbjornson]

https://stat.ethz.ch/pipermail/r-devel/2017-October/075023.html

This has now been mostly fixed in R-devel. What remains to be resolved
is that some packages with custom make files cannot be installed from
source (when R is installed into a directory with space in its name and
short file names are not available)

Tomas

[wch]

Great. Here's the relevant commit: wch/r-source@4fc4867

[JoWi2]

I just ran into the same issue, following Hadley's instructions on how to "make" the ggplot2 book.

'make' is not recognized as an internal or external command, operable program or batch file.
Exited with status 1.

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)
Thanks!

---

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!).
Instead of the coveted PDF I get

$ make
mkdir -p book/tex
mkdir -p book/tex/_figures
mkdir -p book/tex/diagrams
cp book/ggplot2-book.tex book/tex/ggplot2-book.tex
Rscript book/render-tex.R data-manip.rmd
process_begin: CreateProcess(NULL, Rscript book/render-tex.R data-manip.rmd, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [Makefile:23: book/tex/data-manip.tex] Error 2

[oldschoolcool2]

Is this still broken?

> install.packages("finalfit")
installing the source package ‘finalfit’

trying URL 'https://cran.rstudio.com/src/contrib/finalfit_0.7.8.tar.gz'
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\M285595\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"

[JoWi2]

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"`

[wch]

@Ruminare Upgrading to the latest version of R (3.5.0) might help.

[lock]

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/