Skip to content

Windows 7 R (32/64bit) running under cygwin: package not found

12 messages · Aldi Kraja, Jeff Newmiller, Richard M. Heiberger +3 more

#
Hi,
Using R 2.15.1 on Windows 7. Have installed both versions 32 and 64bit.
In both of them among others I have installed a package rgenoud
When I open R gui of 32bit and write library(rgenoud) it responds by 
showing a functional rgenoud version  5.7-8. The same it does on Rgui 
64bit.

Now I am working in cygwin (v. 1.12.4.0) with xwin. Normally before when 
I had installed a package, I only had to call the library with the name 
of the package and R will find the right one to load.

Now when I apply R CMD BATCH script1.R out1.txt, under cygwin the first 
thing it reports:

R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows"
After some generalities it reports
 >library(rgenoud)
Error in library(rgenoud) : there is no package called 'rgenoud'
Execution halted

So my question is why under cygwin in a batch mode, it does not find the 
installed package, which is already installed in my laptop's R?

Thank you in advance,

Aldi
#
On 16/10/2012 12:41 PM, Aldi Kraja wrote:
I think you'll need to debug this yourself, since you haven't given us 
much to work with.  My guess would be that you have a different path so 
you're finding a different R, but it could be something else.  (You 
aren't using the R distributed by Cygwin, are you?  That one doesn't 
work.  I don't know who put it into the Cygwin distribution, but they 
obviously didn't test it.)

Duncan Murdoch
#
Thank you Duncan,

No I did not install R from cygwin. R is installed with windows 7.
I am calling R with a symbolic link from /usr/bin part of cygwin paths, 
but my symbolic link is pointing to /usr/bin/R -> 
/cygdrive/d/RHome/bin/R.exe

Is it possible R is lost in forward paths recognized by cygwin?

You are right I need to test further. Thought someone would have had 
this experience and a solution from previous work.

Aldi
On 10/16/2012 11:51 AM, Duncan Murdoch wrote:
#
Probably because when you run it from Cygwin the R_LIBS variable does not point to the user and install library directories. I don't know how Rgui knows where they are (registry?) but you can look in the .Library and .Library.site variables to see the results. 

In a case like this, posting your sessionInfo() for each case is highly recommended.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
--------------------------------------------------------------------------- 
Sent from my phone. Please excuse my brevity.
Aldi Kraja <aldi at wustl.edu> wrote:

            
#
On 16/10/2012 1:14 PM, Aldi Kraja wrote:
The approach I'd use:

Run rterm or rgui in the same way you were running R. Print 
sessionInfo() and Sys.getenv() and look for strangeness.  (In the 
latter, look at the variables whose names start R_.  See if they're 
different than when you successfully run R gui in the usual way.) If
the interactive run works, then you could put those two diagnostics into 
your script, and try again.

Duncan Murdoch
#
I do not think that this has anything to do with the issue at hand,
but just to clarify ...

On Tue, Oct 16, 2012 at 10:18 AM, Jeff Newmiller
<jdnewmil at dcn.davis.ca.us> wrote:
R for Windows need not use the registry at all, and does so optionally
for just a couple of minor issues. See the R for WIndows FAQ 2.17 for
details.

?library
?.libPaths

describe how R sets/gets library paths (including defaults).

Cheers,
Bert

  
    
#
Thank you all including Bert,

In my opinion the library() when is working in cygwin env., does not 
check the additional libraries, where R installed the additional packages.

So the solution for this problem was to define manually in my programs 
where is located the library of additional packages:
(although I was expecting library() itself to know about the additional 
packages

library('rgenoud',lib.loc='C:/Users/aldi/Documents/R/win-library/2.15')
This solved the problem. Now R works again in cygwin. :-)

Thanks,

Aldi
On 10/16/2012 1:19 PM, Bert Gunter wrote:
#
On 16/10/2012 3:02 PM, Aldi Kraja wrote:
Windows defines various environment variables to set a user's home 
directory, and Cygwin sets different ones.  R assumes the user library 
is in there.  I forget which variable to look in, but for you, Windows 
thinks your home directory is C:/Users/aldi, and Cygwin probably thinks 
it is something like C:/cygwin/home/aldi.

You can override this by setting the R_LIBS_USER variable in Cygwin to 
C:/Users/aldi/Documents/R/win-library/2.15 before you start R; then 
things should be fine.

Duncan Murdoch
#
Duncan wrote
  > You can override this by setting the R_LIBS_USER variable in Cygwin to
  > C:/Users/aldi/Documents/R/win-library/2.15 before you start R; then
  > things should be fine.

If you use R_LIBS_USER then you have to be careful when later calling .libPaths
to add more libraries:
  % env R_LIBS_USER=/homes/bill/packages/Rlib R --quiet
  > .libPaths()
  [1] "/homes/bill/packages/Rlib"
  [2] "/opt/sw/R/R-2.15.1.atlas1/lib/R/library"
  > print(.libPaths("/tmp")) # loses library specified by R_LIBS_USER
  [1] "/tmp"
  [2] "/opt/sw/R/R-2.15.1.atlas1/lib/R/library"

If you use R_LIBS_SITE instead of R_LIBS_USER then your chosen library
sticks around (it is saved in base::.Library.site, which is used by .libPaths())
  % env R_LIBS_SITE=/homes/bill/packages/Rlib R --quiet
  > .libPaths()
  [1] "/homes/bill/packages/Rlib"
  [2] "/opt/sw/R/R-2.15.1.atlas1/lib/R/library"
  > print(.libPaths("/tmp")) # keeps library specified by R_LIBS_SITE
  [1] "/tmp"
  [2] "/homes/bill/packages/Rlib"
  [3] "/opt/sw/R/R-2.15.1.atlas1/lib/R/library"

The difference between R_LIBS_USER and R_LIBS_SITE seems odd to me.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com