Skip to content

R CMD install: problem quoting spaces when calling gzip?

6 messages · Jochen Laubrock, Brian Ripley, Simon Urbanek

#
There appears to be a quoting problem in the way R CMD install handles file names containing spaces, more specifically, in the way the argument is passed through to gzip.

The install.packages command

(from R)
install.packages("~/Projects/R library/bar/eyetrackR_0.13.tar.gz", repos = NULL, type = "source")

expands to

system("R_LIBS='/Users/foo/Library/R/2.10/library' "/Library/Frameworks/R.framework/Resources/bin/R CMD INSTALL -l '/Users/foo/Library/R/2.10/library'   '/Users/foo/Projects/R\ library/bar/eyetrackR_0.13.tar.gz'")

and gives the same error messages as the following commands from Terminal.app on Mac OS X

(from bash)
R CMD install /Users/foo/Projects/R\ library/bar/eyetrackR_0.13.tar.gz
R CMD install "~/Projects/R library/bar/eyetrackR_0.13.tar.gz"
R CMD install '~/Projects/R library/bar/eyetrackR_0.13.tar.gz'

, namely (the error messages): 

gzip: /Users/foo/Projects/R.gz: No such file or directory
gzip: library/bar/eyetrackR_0.13.tar.gz: No such file or directory


The following commands do work 

(from R)
setwd("~/Projects/R library/bar/")
install.packages("eyetrackR_0.13.tar.gz", repos = NULL, type = "source")

(from bash)
cd ~/Projects/R\ library/bar/
R CMD install eyetrackR_0.13.tar.gz

Interestingly, if the file is unpacked on the command line (tar xzvf), then both R CMD install and install.packages work fine using the quoted path name syntax, i.e.,

R CMD install /Users/foo/Projects/R\ library/bar/eyetrackR
install.packages("~/Projects/R library/bar/eyetrackR", repos = NULL, type = "source")

Is this a known problem? I searched the archives, but did not find a decisive answer (only some rather old posts suggesting not to use path names containing spaces--unfortunately this is not an option in the managed Windows environment I need to work in next week).

Sorry for the long post and thanks for your time,
Jochen

----
Jochen Laubrock, Dept. of Psychology, University of Potsdam,
Karl-Liebknecht-Strasse 24-25, 14476 Potsdam, Germany
phone: +49-331-977-2346, fax: +49-331-977-2793
#
You haven't told us your version of R (nor any of the other 
information requested in the posting guide).  As far as I can see this 
works in 2.11.0 alpha.
On Fri, 26 Mar 2010, jochen laubrock wrote:

            
So that is fine.
the documented command is INSTALL.
Yes, and INSTALL is not designed to work with paths with spaces in on 
Unix-alikes.
It is a known restriction.
some rather old posts suggesting not to use path names containing spaces--unfortunately this is not an option in the managed Windows environment I need to work in next week).

  
    
#
I am sorry, this was from 2.10.1 on Mac OS X 10.6, so it might be Mac-specific. The behavior is reproducible both from the shell and the GUI version of R (sessionInfo output below). It does not seem to depend on the particular package: it can be reproduced by downloading an archive of a package from CRAN to a path containing spaces and calling
install.packages("path/with spaces/downloadedPackage.tar.gz", repos = NULL, type = "source"):
[...] downloaded 300 Kb
     [,1]  [,2]                                   
[1,] "gam" "~/Projects/R library/tmp/gam_1.01.tgz"
[...]
gzip: /Users/jochen/Projects/R.gz: No such file or directory
gzip: library/tmp/gam_1.01.tgz: No such file or directory
ERROR: cannot extract package from ?/Users/jochen/Projects/R library/tmp/gam_1.01.tgz?

# /usr/bin/R
R version 2.10.1 (2009-12-14) 
x86_64-apple-darwin9.8.0 

locale:
[1] de_DE.UTF-8/de_DE.UTF-8/C/C/de_DE.UTF-8/de_DE.UTF-8

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

# R.app (RAqua)
R version 2.10.1 (2009-12-14) 
i386-apple-darwin9.8.0 

locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
On Mar 26, 2010, at 10:19 , Prof Brian Ripley wrote:

            
Does that mean that it has been re-designed to work with paths containing spaces on Unix-alikes?
sorry
#
So please try 2.11.0 alpha, as I believe this is already fixed (not 
least, gzip is not called on that platform).  Also, I suspect setting 
the envir variable TAR to 'internal' would work on 2.10.1 (but my 
Mac is at home).

Another thing that does not work with spaces in file names is 
command-line completion of filenames (in R, I did not try R.app).  If 
spaces in filenames work (other than on Windows) it is somewhat 
accidental.  Reports of instances where they do not, with patches 
against current sources, would be considered but as low priority.

BTW, 'install' works on case-insensitive file systems, but it is 
likely to stop working at any time: as on Windows, 'R CMD' is being 
moved away from Perl/sh scripts to direct use of R.
On Fri, 26 Mar 2010, jochen laubrock wrote:

            
I did try it on a Mac, but I did not try 2.10.1, since the 'upgrade 
before posting' request in the posting guide did apply, and we are 
busy enough with 2.11.0 alpha.

The behavior is reproducible both from the shell and the GUI version of R (sessionInfo output below). It does not seem to depend on the particular package: it can be reproduced by downloading an archive of a package from CRAN to a path containing spaces and calling
No.  It is an unintentional side-effect of

     o   R CMD INSTALL now uses the internal untar() in package utils:
         this ensures that all platforms can install bzip2- and
         xz-compressed tarballs.

  
    
#
Yes, that worked, thanks a lot! Looking forward to the 2.11.0 release.
* installing *source* package ?eyetrackR? ...
** R
** data
** demo
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
* DONE (eyetrackR)
R version 2.11.0 alpha (2010-03-26 r51420) 
x86_64-apple-darwin10.2.0 

locale:
[1] de_DE.UTF-8/de_DE.UTF-8/C/C/de_DE.UTF-8/de_DE.UTF-8

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


btw, this is probably known, but ... the gfortran in /usr/bin (gcc version 4.2.1 (Apple Inc. build 5646)) did not work (complaining about /usr/lib/libgfortran.dylib, missing required architecture x86_64), but a different gfortran located in /usr/local/bin did (gcc version 4.2.3, probably from Simon Urbanek's page)
On Mar 26, 2010, at 11:51 , Prof Brian Ripley wrote:

            
----
Jochen Laubrock, Dept. of Psychology, University of Potsdam,
Karl-Liebknecht-Strasse 24-25, 14476 Potsdam, Germany
phone: +49-331-977-2346, fax: +49-331-977-2793
#
On Mar 26, 2010, at 8:24 , jochen laubrock wrote:

            
I suspect you have installed broken 3rd party Fortran at some point.  
Our apple build Fortran uses static libraries and includes all  
architectures. I would suggest removing libgfortran.dylib (and any  
other left-overs from 3rd party compilers).

Cheers,
Simon