HOME must be set

[rubenarslan]

if (Sys.info()['sysname'] == "Linux" && is.na(Sys.getenv("HOME", unset = NA))) { stop("The 'HOME' environment variable must be set before running Pandoc.")

Why does it have to be set and to what? I'd like to call rmarkdown using Rstudio, but can't because HOME isn't set. As far as I can see in the codebase, you do not actually use the param?

[jjallaire]

This is required because pandoc can crash when HOME isn't set.

I'm surprised that HOME isn't set in RStudio. All of our test systems running Linux with RStudio have HOME defined.

[rubenarslan]

My bad! I wanted to write using openCPU. Rmarkdown works fine using the Rstudio server that is shipped with openCPU.

[rubenarslan]

Also, to call pandoc --version from the command line in Ubuntu without getting hangs I had to set LC_ALL, not unset it. Then I saw your snippet unsetting it in rmarkdown, now I'm confused (I also may have broken my working pandoc-rstudio-combo).

[rubenarslan]

Ok, so I looked into this some more.

If locale throws warnings, I seem to get the hang in pandoc --version, but this can happen if LC_CTYPE is not set too (because then it tries LC_ALL apparently). I can unset LC_ALL and set LC_CTYPE, but it seems LC_ALL just has to be valid (e.g. de_DE.UTF-8) if it is used.

Also, one of my openCPU Ubuntu machines seems to be knitting fine, but the other complains that LANG is not set. I haven't touched LANG on either machine and in interactive Rstudio sessions Sys.getenv("LANG", unset=NA) yields NA on both machines. I'm confused.

[jjallaire]

I'm confused too :-)

If you could convey this as a reproducible bug report or pull request that would be ideal.

On Tue, May 27, 2014 at 1:33 PM, Ruben C. Arslan notifications@github.comwrote:

Ok, so I looked into this some more.

If locale throws warnings, I seem to get the hang in pandoc --version, but this can happen if LC_CTYPE is not set too (because then it tries LC_ALL apparently). I can unset LC_ALL and set LC_CTYPE, but it seems LC_ALL just has to be valid (e.g. de_DE.UTF-8) if it is used.

Also, one of my openCPU Ubuntu machines seems to be knitting fine, but the other complains that LANG is not set. I haven't touched LANG on either machine and in interactive Rstudio sessions Sys.getenv("LANG", unset=NA)yields NA on both machines. I'm confused.

— Reply to this email directly or view it on GitHubhttps://github.com/rstudio/rmarkdown/issues/109#issuecomment-44308100 .

[yihui]

Here is another one who had the LANG problem as well, and I could not reproduce, either: http://stackoverflow.com/questions/23851449/lang-error-knitting-document-in-r-studio-preview-0-98-864 It sounds unlikely to me that LANG can be missing on some platforms...

[jjallaire]

Not sure how or why LANG is unset in RStudio Server, but I made the following change to rmarkdown to workaround the issue in the case where it is: https://github.com/rstudio/rmarkdown/commit/bb2d87f8b8cc18234039130ceecfc8180dc90ea4

On Wed, May 28, 2014 at 12:45 PM, Yihui Xie notifications@github.comwrote:

Here is another one who had the LANG problem as well, and I could not reproduce, either: http://stackoverflow.com/questions/23851449/lang-error-knitting-document-in-r-studio-preview-0-98-864It sounds unlikely to me that LANG can be missing on some platforms...

— Reply to this email directly or view it on GitHubhttps://github.com/rstudio/rmarkdown/issues/109#issuecomment-44433540 .

[rubenarslan]

If you have any advice on how to reproduce this, let me know, I don't know where to start. I have two openCPU VMs with Rstudio, one had the problem the other didn't and I think there was no openCPU or Rstudio update since I cloned VM2 from VM1. The one with the LANG problem is the more up-to-date one.

[yihui]

@rubenarslan We were jut bitten by this problem as well. It is not clear to us why LANG was unset in the system, and our current workaround is to define LANG=C.UTF-8 in Renviron.site (I guess this can also be done in /etc/environment if you want LANG to be set the the whole system).

[jjallaire]

rmarkdowon also now sets LANG to C.UTF-8 before calling pandoc (if it's not already set to something else).

On Wed, Jun 4, 2014 at 3:35 PM, Yihui Xie notifications@github.com wrote:

@rubenarslan https://github.com/rubenarslan We were jut bitten by this problem as well. It is not clear to us why LANG was unset in the system, and our current workaround is to define LANG=C.UTF-8 in Renviron.site (I guess this can also be done in /etc/environment if you want LANG to be set the the whole system).

— Reply to this email directly or view it on GitHub https://github.com/rstudio/rmarkdown/issues/109#issuecomment-45140490.

[rubenarslan]

Sorry, for reopening again, but I'm having trouble using rmarkdown via openCPU again. Unfortunately even though I use the same opencpu pandoc and rmarkdown version as http://public.opencpu.org/ocpu/test it works on @jeroenooms server, but not on mine. LC_ALL, LANG, HOME and LC_CTYPE are also all identical (in addition to the fact that rmarkdown uses "with_pandoc_safe_environment"). If I use the openCPU testing interface to call ../library/base/R/identity/json x = strsplit(strsplit(system("pandoc --version", intern = T), "\n")[[1]][1], " ")[[1]][2]

I get "1.12.3.3" on both servers.

However, calling ../github/rstudio/rmarkdown/R/pandoc_available/json yields true on Jeroen's server, but

subscript out of bounds In call: strsplit(version_info, "\n")[[1]]

on mine.

I' could try installing an up-to-date pandoc now, something that I've avoided so far because of the work involved and because I'm not even sure that they fixed the super annoying "pandoc --version" hang.

Also, rmarkdown appears to be using an older pandoc than my system, so maybe updating it won't do any good:

rmarkdown::pandoc_available("1.12.3")
## [1] TRUE
rmarkdown::pandoc_available("1.12.3.1")
## [1] FALSE

[rubenarslan]

I updated pandoc (using cabal) to 1.13.1. It doesn't have the pandoc --version hang anymore.

In so doing, I discovered yet another pandoc installation in /usr/bin. OpenCPU when calling system("pandoc --version", intern = T) looked only in /usr/bin, even though there was another pandoc binary in /usr/local/bin and even though calling Sys.getenv("PATH") via openCPU yields this search path in which /usr/local/bin is clearly before /usr/bin.

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Anyway, I just substituted all versions of pandoc with the most recent one, making copies, because ln -s /root/.cabal/bin/pandoc /usr/bin/ apparently wasn't enough. A difficult birth, but now it works.

[github-actions[bot]]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.