Just to close this off, in case it helps anyone else in a similar
situation...
Background: I have R installed on a UNC share with a site library named by
major and minor version, thus:
\\campden\shares\Workgroup\Stats 'root'
\\campden\shares\Workgroup\Stats\R base for R related things
\\campden\shares\Workgroup\Stats\R\R-2.13.1 one R installation
\\campden\shares\Workgroup\Stats\R\library site libraries go here
\\campden\shares\Workgroup\Stats\R\library\2.13 site library for R 2.13.x
I took the hint and mapped a drive from which to start R.
Because I don't have a pre-determined drive letter to use I wrote a little
.bat file to do the job:
------------------
REM find or 'net use' a drive mapped to stats share
set remote=\\campden\shares\Workgroup\Stats
set drive=
:check
for /f "delims=*" %%a in ('net use ^| find "%remote%"') do set drive=%%a
if not defined drive net use * %remote% /persistent:NO>nul & goto check
set StatsDrive=%drive:~13,2%
REM using that drive
REM a) ensure GTK+ is in the path (for packages such as 'playwith')
REM b) start 32 bit R
set path=%StatsDrive%/R/GTK+/bin;%path%
start %StatsDrive%\R\R-2.13.1\bin\i386\Rgui.exe
----------------------------------------
That's a bit flakey, depending on the exact format of the output from 'net
use'. If anyone has a better solution, I'll appreciate it!
Now the site library:
Putting a UNC path into Renviron.site thus...
R_LIBS_SITE=//campden/shares/workgroup/stats/R/library/%v
... was the cause of my original problem.
I can't put it in as a mapped drive, because I don't know the drive until
run time.
I tried to work up and down from the drive mapped R_HOME...
R_LIBS_SITE=${R_HOME}/.../library/%v
... but that didn't work in Renviron.site.
> Sys.getenv("R_HOME")
[1] "Z:/R/R-2.13.1"
... which is fine, but...
> Sys.getenv("R_LIBS_SITE")
[1] "Z:RR-2.13.1/.../library/2.13"
I think this may be something to do with this quote from ?Startup...
"value is then processed in a similar way to a Unix shell: in particular the
outermost level of (single or double) quotes is stripped, and backslashes
are removed except inside quotes"
...but I don't have any control over R_HOME, specifically how and when
forward- or back-slashes are used or removed.
In the end I used Renviron.site just to pass the version information...
R_Libs_Site=%v
That directory doesn't exist so doesn't get added to .libPaths()
In Rprofile.site I worked up and down from R_HOME...
.libPaths(file.path(dirname(R.home()),"library",Sys.getenv("R_Libs_Site")))
... which seems to do the job.
It isn't pretty, and the .bat file will probably need changing in future
versions of Windows.
But by the time R has started there isn't a UNC path in sight.
I still think I've probably re-invented a wheel and ended up with something
square, but it is going round.
Best regards,
Keith Jewell
"Keith Jewell" <k.jew...@campden.co.uk> wrote in message
news:j22q11$9u9$1...@dough.gmane.org...
> Thanks Uwe.
>
> I'm aware (and have been forcefully reminded) that using a mapped drive
> avoids these problems. But there is no single drive letter which I can use
> site-wide, so I have problems with things like R_LIBS_SITE. As I've
> outlined I'm exploring a range of solutions, including mapping a drive
> where I can.
>
> I posted in the hope of learning from and perhaps helping those with
> similar problems. I hope that it is permissible to discuss non-canonical
> use of R on this list, I certainly did not intend disrespect for the R
> developers (or to make typing errors).
>
> Best regards
>
> Keith Jewell
>
> "Uwe Ligges" <lig...@statistik.tu-dortmund.de> wrote in message
> news:4e44091e.7090...@statistik.tu-dortmund.de...
>> This is extremely tricky since Windows does not always accept "//" rather
>> than "\\". Additionally, there is not implemented system call in Windows,
>> hence ?Sys.glob tells us a "partial emulation" is provided and "An
>> attempt is made to handle UNC paths starting with a double backslash."
>>
>> As you have seenm this does not work everywhere, therefore it is
>> advisable to run R from mapped drives - as I am doing in the network of
>> our university for 13 years without problems now.
>>
>> Best,
>> Uwe Ligges
>>
>>
>> On 11.08.2011 18:29, Keith Jewell wrote:
>>> Hi,
>>>
>>> Back in June I posted the message below, but had no replies. I've made a
>>> little progress since then so this is to update anyone interested (!)
>>> and to
>>> ask for comments.
>>>
>>> Brief problem statement:
>>> Under Windows, some parts of R don't handle UNC paths beginning with
>>> backslashes. Specifically
>>> a) Sys.glob() fails to find some files breaking (e.g.) Rcmdr plugins
>>> Sys.glob(file.path(.libPaths(), "*/etc/menus.txt"))
>>> fails to find files which are there
>>>
>>> b) update.packages(ask='graphics') fails when copying the updates into
>>> the
>>> destination folders
>>>
>>> In Renviron.site I define the site library with forward slashes, not
>>> backslashes thus...
>>> R_LIBS_SITE=//campden/shares/workgroup/stats/R/library/%v
>>> ... but the startup process seems to replace them with forward slashes.
>>> I guess because .libPaths with a 'new' argument calls normalizePath
>>> which
>>> changes leading slashes to backslashes, even with winslash="/"
>>>> normalizePath("//campden/shares/workgroup/stats/R/library",
>>>> winslash="/")
>>> [1] "\\\\campden/shares/workgroup/Stats/R/library"
>>>
>>> I've corrected (??) this by inserting a line into Rprofile.site
>>> assign(".lib.loc", gsub("\\", "/", .libPaths(), fixed=TRUE),
>>> env=environment(.libPaths))
>>> That seems to fix problem (a) above, which was affecting a number of
>>> users.
>>> But have I broken anything else?
>>>
>>> I'm still experiencing problem (b).
>>> I'm the only person on site who updates packages so I've mapped a drive
>>> letter (L:) and in my own .Rprofile I have a line
>>> assign(".lib.loc", sub("//campden/shares/workgroup/Stats", "L:",
>>> .libPaths(), ignore.case = TRUE), env=environment(.libPaths))
>>>
>>> So that's OK as far as it goes, but it's all a bit messy!
>>> If .libPaths is called with a 'new' argument it will breaks things
>>> again.
>>> normalizePath seems to produce paths that don't work with Sys.glob.
>>>
>>> I have the feeling I'm being silly and making hard work of all this.
>>>
>>> Any comments? Suggestions?
>>>
>>> Best regards, and thanks in advance/
>>>
>>> Keith Jewell
>>>
>>> "Keith Jewell"<k.jew...@campden.co.uk> wrote in message news:...
>>>> Hi,
>>>>
>>>> Back in 2010 I had a problem with 'update.packages()', which I worked
>>>> around by mapping a drive letter to a UNC path [described in
>>>> <http://finzi.psych.upenn.edu/Rhelp10/2010-February/229820.html> but
>>>> my
>>>> current workaround is
>>>> assign(".lib.loc", sub("\\\\\\\\Server02/stats", "L:", .libPaths(),
>>>> ignore.case = TRUE), env=environment(.libPaths))].
>>>>
>>>> More recently a colleague had problems using the 'FactoMineR' plug in
>>>> for
>>>> the Rcmdr package;
>>>> a) directly loading 'RcmdrPlugin.FactoMineR' opened and "crashed" R
>>>> Commander;
>>>> b) opening R Commander without FactoMiner, the Tools option 'Load Rcmdr
>>>> plug-in(s)...' was greyed out.
>>>>
>>>> It transpired that in .libPaths() the path to the library holding
>>>> 'RcmdrPlugin.FactoMineR' was specified as a UNC address:
>>>> \\\\Server02/stats/R/library/2.13>. Mapping a virtual drive letter
>>>> (e.g.
>>>> L:) and specifying the path in .libPaths() as a 'local file system'
>>>> (LFS)
>>>> address<L:/R/library/2.13> fixed the problem.
>>>>
>>>> I contacted Professor Fox (maintainer of Rcmdr) who told me that Rcmdr
>>>> finds plug-in packages via the command
>>>> plugins<- unlist(lapply(.libPaths(), function(x)
>>>> Sys.glob(file.path(x,
>>>> "*/etc/menus.txt"))))
>>>> Because file.path and Sys.glob are both vectorised I think (but am not
>>>> certain) that this could be simplified to:
>>>> plugins<- Sys.glob(file.path(.libPaths(), "*/etc/menus.txt"))
>>>> but that's by the way, the problem seems to lie in Sys.glob under
>>>> Windows
>>>> operating systems.
>>>>
>>>> I note that 'help(Sys.glob)' on my Windows system differs from
>>>> <http://finzi.psych.upenn.edu/R/library/base/html/Sys.glob.html>.
>>>> The latter says "For precise details, see your system's documentation
>>>> on
>>>> the glob system call. There is a POSIX 1003.2 standard<snip> The rest
>>>> of these details are indicative (and based on the POSIX standard)".
>>>> On Windows "The glob system call is not part of Windows, and we supply
>>>> a
>>>> partial emulation.<snip> An attempt is made to handle UNC paths
>>>> starting
>>>> with a double backslash" which doesn't really inspire confidence.
>>>>
>>>> This was discussed in a 2009 R-devel thread starting here
>>>> <https://stat.ethz.ch/pipermail/r-devel/2009-June/053879.html>, but the
>>>> patch proposed in that thread seems not to have been implemented (??).
>>>>
>>>> Trying to avoid Sys.glob in the Rcmdr application I came up with this:
>>>> list.files(path=file.path(list.files(path=.libPaths(),
>>>> full.names=TRUE), "etc"), pattern="^menus\\.txt$", full.names=TRUE)
>>>> It seems to give identical results to Sys.glob for mapped drives, works
>>>> with UNC paths in Windows, and seems quite fast.
>>>>
>>>> So my questions relate to diagnosis, prognosis, and prescription
>>>> (cure?).
>>>>
>>>> 1) Diagnosis: Am I correct that my problem(s) originate in the "partial
>>>> emulation" of glob in Windows.
>>>>
>>>> 2) Prognosis: If so, is there any likelihood that the emulation will
>>>> improve in the near future?
>>>>
>>>> 3) Prescription: If not:
>>>>
>>>> a) is assign(".lib.loc", sub("\\\\\\\\Server02/stats", "L:",
>>>> .libPaths(),
>>>> ignore.case = TRUE), env=environment(.libPaths))
>>>> a reasonable workaround in a specific case?
>>>>
>>>> b) is list.files(path=file.path(list.files(path=.libPaths(),
>>>> full.names=TRUE), "etc"), pattern="^menus\\.txt$", full.names=TRUE)
>>>> a reasonable replacement for the Sys.glob() construction in Rcmdr? I
>>>> don't
>>>> want to suggest to Prof. Fox an amendment which fixes my problem but
>>>> 'breaks' it for others!
>>>>
>>>> Thanks in advance,
>>>>
>>>> Keith Jewell
>>>>
>>>> R version 2.13.0 (2011-04-13)
>>>> Platform: i386-pc-mingw32/i386 (32-bit)
>>>>
>>>> locale:
>>>> [1] LC_COLLATE=English_United Kingdom.1252
>>>> [2] LC_CTYPE=English_United Kingdom.1252
>>>> [3] LC_MONETARY=English_United Kingdom.1252
>>>> [4] LC_NUMERIC=C
>>>> [5] LC_TIME=English_United Kingdom.1252
>>>>
>>>> attached base packages:
>>>> [1] datasets grDevices splines graphics stats utils tcltk
>>>> [8] tools methods base
>>>>
>>>>
>>>>
>>>
>>> ______________________________________________
>>> R-help@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>> http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>
>
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
