load fails on Windows machines if user has a space in their user name

[christophsax]

reported and discussed here christophsax/seasonal#146, adding it to keep track of.

[jbkunst]

Hi @christophsax ,

Obviously you fix is better than what I did ;) (I did it because I cant install the "quote-windows" branch.

I have a fresh R 3.2.3 installation and the lastest cran version of the packages. I tried again and I keep with the .configure.win error. There's a way to avoid this sh files? (In my fork I deleted this sh files and it can be installed devtools::install_github("jbkunst/x13binary"))

> library(devtools)
> install_github("x13org/x13binary", ref = "bug/quote-windows")
Downloading GitHub repo x13org/x13binary@bug/quote-windows
from URL https://api.github.com/repos/x13org/x13binary/zipball/bug/quote-windows
Installing x13binary
"C:/PROGRA~1/R/R-32~1.3/bin/x64/R" --no-site-file --no-environ --no-save --no-restore CMD INSTALL "C:/Users/Joshua  \
  K/AppData/Local/Temp/Rtmp0CXTD8/devtoolsda840c31594/x13org-x13binary-cf8a9bf" --library="C:/Program Files/R/R-3.2.3/library" --install-tests 

* installing *source* package 'x13binary' ...
Warning: running command 'sh ./configure.win' had status 127
ERROR: configuration failed for package 'x13binary'
* removing 'C:/Program Files/R/R-3.2.3/library/x13binary'
* restoring previous 'C:/Program Files/R/R-3.2.3/library/x13binary'
Error: Command failed (1)
> sessionInfo()
R version 3.2.3 (2015-12-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

locale:
[1] LC_COLLATE=Spanish_Chile.1252  LC_CTYPE=Spanish_Chile.1252    LC_MONETARY=Spanish_Chile.1252 LC_NUMERIC=C                   LC_TIME=Spanish_Chile.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] devtools_1.10.0

loaded via a namespace (and not attached):
[1] httr_1.1.0    R6_2.1.2      tools_3.2.3   withr_1.0.1   curl_0.9.5    memoise_1.0.0 git2r_0.13.1  digest_0.6.9 

[christophsax]

Thanks. Ok, that explains the different behaviour of our versions. By removing configure, you are just skipping the main point of x13binary, which is to download the X-13 binaries. You have to specify the path to X-13 manually, as in previous versions of seasonal, which is probably what you did.

However, I would be really interested why the configure script has on your system failed. Can you give this line a quick try? (in your R console)

download.file('https://github.com/x13org/x13prebuilt/raw/master/windows/x13ashtml.zip', 'x13ashtml.zip', mode = "wb")

[ellisp]

I have the same problem as @jbkunst (for what it's worth, I think you've solved the "space in the name" problem and that this is unrelated). I can run that download.file line in R no problem. Looking at configure.win and running it in a terminal one line at a time I found unzip -u x13ashtml.zip works in a MINGW32 terminal but not in a cmd terminal. In fact the cmd terminal can't find sh either. So it's some kind of path problem.

[christophsax]

Thanks, Peter. At least some progress. Can we give this one a try:

devtools::install_github("x13org/x13binary", ref = "bug/nozip-windows")

This should download the unziped binary.

[eddelbuettel]

Regarding

Looking at configure.win and running it in a terminal one line at a time I found unzip -u x13ashtml.zip works in a MINGW32 terminal but not in a cmd terminal. In fact the cmd terminal can't find sh either. So it's some kind of path problem.

we generally assume that configure.win is called by R when installing/unpacking and hence having access to all the PATH components needed / used by R. That may include Rtools if on a box where R packages are written. Maybe we have to try harder to do it all from within R just relying on R commands -- as we can assume Rscript and R.

[christophsax]

Calling the commands from R is simple (and the unzip with unzip = "internal" should work on all win installations, according to ?unzip), but how can we start an R script during installation?

[ellisp]

I get the same error Warning: running command 'sh ./configure.win' had status 127 with the bug/nozip-windows version. Looks like sh isn't in the path in a cmd terminal. Obviously I could fix that, but others will have similar problems.

BTW install.packages("x13binary") works fine for me from CRAN (although {seasonal} won't load because of the 'space in user name' error that started this thread).

[eddelbuettel]

Yes, I think there are two issues here:

1. You want to build from source. That works if you have Rtools. It does not work when you don't have Rtools, and poor Christoph is trying too hard to make up for it. We should just die with a loud error here.
2. You do not need to build from source. That was the whole point of providing pre-built binaries.

Now, we could rewrite configure.win to be an R-script-in-a-string which we pass to Rscript.exe as the latter can be assumed. Worth it?

[ellisp]

Except that I do have Rtools, and I install other packages from GitHub all the time, and indeed build my own packages without problems too...

[eddelbuettel]

Interesting. Then your PATH is foobar and that is beyond our control.

Our package builds on sane environments such as win-builder and the CRAN machines. If yours requires special pixies, may we rely on you to supply the pixie dust? We don't have access to your machine so ... you get to lead this, or it'll stay the way it is.

[christophsax]

So the unzip is not the problem, but rather sh not being found. Rewriting configure.win as an R-script wouldn't help in this case. Hmmm.

[ellisp]

@eddelbuettel - just pointing out that @jbkunst and I both had the same problem and thought we were being helpful, but that's fine, do what you like. I have plenty of ways to make x13 work on my various systems.

Unsubscribing from this thread.

[christophsax]

Thanks again Peter, your help is appreciated. I also think we made some progress. If I got it right, the sh problem should disappear when on CRAN, and the space issue is resolved as well. I guess I will switch to back to the zip version and we can close the issue.

[jbkunst]

@christophsax No problem with download.file.

Well, I wish the 100% of windows user have a sane enviorment (which I think windows by default is not 😆). If I can help you with some test just let me know.

Thank you again for your support and for this peanut butter and jelly 😉

[eddelbuettel]

😄

I tend to agree that Windows is not all that sane -- but then again we set out to make this feasible despite all those cumbersome realities. One step at a time, and feedback is really helpful. I think what @christophsax just added should really help. Let's take it from there.

[christophsax]

This should be resolved in the latest CRAN release (0.1.1, available as binary now). To update:

install.packages("x13binary")

[ellisp]

yes, works fine for me thanks

[eddelbuettel]

Yay! Thanks for reporting back.

[eddelbuettel]

@ellisp I had been meaning to glance at ggeas not realising it is yours.... Any plans for a CRAN release?

[ellisp]

@eddelbuettel Yes, I do plan to put it on CRAN, I just want to tidy up a few things first.

[eddelbuettel]

@ellisp Great. I'll have a use case for it, but that too needs some clean up first :)