Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



I tried to install ramnathv's slidify library from github using the devtools library and was greeted by the following:

Installing github repo slidify/master from ramnathv
Downloading from
Installing package from /tmp/RtmpOFEJuD/
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 (

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:


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; 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
Comment by John Henderson (jwhendy) - Monday, 09 December 2013, 17:18 GMT
See this question on SO and the comment from Dason:

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?
Comment by Arno Gaboury (gabx) - Friday, 31 January 2014, 12:39 GMT
I modified the wiki after I ran into same issue. Not sure if we can call this a bug, but the /etc/R/Renviron, generated from by configure should certainly contend these two lines:

## Default zip/unzip commands
R_UNZIPCMD = ${R_UNZIPCMD-'/usr/bin/unzip '}
R_ZIPCMD = ${R_ZIPCMD-'/usr/bin/zip '}
Comment by Ronald van Haren (pressh) - Friday, 31 January 2014, 12:57 GMT
I suppose zip/unzip must be installed during build for it to be populated in Renviron. Does it make most sense to add zip/unzip as dependencies or as optional dependencies?
Comment by Arno Gaboury (gabx) - Friday, 31 January 2014, 13:22 GMT
I would say the simplest way for your package management is to add zip/unzip as dependencies then modify accordingly.
Please let me know if you make any change as the wiki warning in such case shall be removed. TY