FS#38030 - [r] .Options$unzip not populated by default
Attached to Project:
Arch Linux
Opened by John Henderson (jwhendy) - Thursday, 05 December 2013, 19:09 GMT
Last edited by Ronald van Haren (pressh) - Friday, 31 January 2014, 14:13 GMT
Opened by John Henderson (jwhendy) - Thursday, 05 December 2013, 19:09 GMT
Last edited by Ronald van Haren (pressh) - Friday, 31 January 2014, 14:13 GMT
|
Details
Description:
I tried to install ramnathv's slidify library from github using the devtools library and was greeted by the following: ---------- install.packages("devtools") library(devtools) install_github("slidify","ramnathv") Installing github repo slidify/master from ramnathv Downloading slidify.zip from https://github.com/ramnathv/slidify/archive/master.zip Installing package from /tmp/RtmpOFEJuD/slidify.zip Error in unzip(src, exdir = target, unzip = getOption("unzip")) : 'unzip' must be a single character string ---------- In looking at various sources of documentation, it appears that R is supposed to pickup an installed unzip utility and store it in .Options$unzip during installation, which isn't happening at least on my system. From options documentation (http://stat.ethz.ch/R-manual/R-patched/library/base/html/options.html) ---------- unzip: a character string, the path of the command used for unzipping help files, or "internal". Defaults to the value of R_UNZIPCMD, which is set in ‘etc/Renviron’ if an unzip command was found during configuration. ---------- This would be stored in .Options, however not the output: > .Options$unzip [1] "" There's nothing there. I'm not positive this is a bug, but since R states it should pick up any unzip options that are installed, it would seem that if a user installs the Arch binary and has unzip installed... it should be populated. Or is my thinking incorrect on this? For reference, unless the behavior has changes, I installed this same library (slidify using devtools) on another Arch machine using the same Arch package, but either v. 3.0.0 or 3.0.1. Either my system has changed, or perhaps a previous version of R worked and does not any longer with v. 3.0.2. Editing ~/.Renviron and adding the following line remedies the issue: R_UNZIPCMD=/usr/bin/unzip Additional info: * package version(s) R: 3.0.2-1 unzip: 6.0-6 devtools: 1.4.1 $ /usr/bin/unzip -v UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send bug reports using http://www.info-zip.org/zip-bug.html; see README for details. Steps to reproduce: $ sudo pacman -S r $ R > .Options$unzip |
This task depends upon
Closed by Ronald van Haren (pressh)
Friday, 31 January 2014, 14:13 GMT
Reason for closing: Fixed
Additional comments about closing: 3.0.2-2 have zip/unzip dependencies and populated Renviron for those
Friday, 31 January 2014, 14:13 GMT
Reason for closing: Fixed
Additional comments about closing: 3.0.2-2 have zip/unzip dependencies and populated Renviron for those
If the answer is, in fact, that the Arch binary leaves this unset due to not knowing if unzip is installed, I will edit the Arch wiki to make note that this should be set in ~/.Renviron. I'm still curious why I didn't run into this issue on 3.0.0 or 3.0.1 when I installed the same github library which, presumably, required unzip as well?
## Default zip/unzip commands
R_UNZIPCMD = ${R_UNZIPCMD-'/usr/bin/unzip '}
R_ZIPCMD = ${R_ZIPCMD-'/usr/bin/zip '}
Please let me know if you make any change as the wiki warning in such case shall be removed. TY