I think you can also do this from within R (e.g. in your .Rprofile) using the R.utils package;
library("R.utils") System$mapDriveOnWindows("K", "\\\\campden\\shares\\Workgroup\\Stats") driveLetters <- System$getMappedDrivesOnWindows() System$unmapDriveOnWindows("K") These methods utilize 'subst' of MS Windows. /Henrik On Thu, Aug 18, 2011 at 6:12 PM, Keith Jewell <k.jew...@campden.co.uk> wrote: > 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. > ______________________________________________ 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.