UNC windows path beginning with backslashes: normalizePath bug??

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.jewell at 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

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.jewell at 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

Sys.getenv("R_HOME")

Sys.getenv("R_LIBS_SITE")

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" <ligges at statistik.tu-dortmund.de> wrote in message 
news:4E44091E.7090309 at 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.jewell at 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

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.jewell at campden.co.uk> wrote in message
news:j22q11$9u9$1 at 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" <ligges at statistik.tu-dortmund.de> wrote in message
news:4E44091E.7090309 at 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.jewell at 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

library("R.utils")

sessionInfo()

System$getMappedDrivesOnWindows()

system("net use")

System$mapDriveOnWindows("K", "\\\\campden\\shares\\Workgroup\\Stats")

driveLetters <- System$getMappedDrivesOnWindows()
driveLetters

System$unmapDriveOnWindows("K")

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.jewell at campden.co.uk> wrote in message
news:j22q11$9u9$1 at 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" <ligges at statistik.tu-dortmund.de> wrote in message
news:4E44091E.7090309 at 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