On 08/11/2012 15:28, Marc Schwartz wrote:
On Nov 8, 2012, at 12:57 AM, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote:
On 07/11/2012 23:12, Marc Schwartz wrote:
On Nov 7, 2012, at 4:58 PM, r <ric.rom...@gmail.com> wrote:
Dear list, I have some .xls files that I need to read into R. I am
able to do so using read.xls in the gdata package, however the
helper functions sheetNames and sheetCount fail. This is the
error:
Unable to open file '~/SharedFolder/MyData/mydata.xls'. Warning:
running command ''/usr/bin/perl'
'/usr/local/lib/R/site-library/gdata/perl/sheetCount.pl'
'~/SharedFolder/MyData/mydata.xls'' had status 2
Googling I found that the problem is caused by the use of the
absolute path ("~/SharedFolder/MyData/") instead of
"/home/r/SharedFolder/MyData/". I use the absolute path because I
work from different computer connected to a shared folder.
This is the discussion I found:
http://stackoverflow.com/questions/11737906/path-specification-when-using-the-r-package-gdata
Is there a way to solve this problem??
Best Riccardo
You can contact the package maintainer (cc'd here) and suggest that
the use of:
normalizePath()
be implemented in the code, which would then do tilde expansion, etc.
when relative file paths are passed rather than absolute paths are
used.
If you just want tilde expansion, it is usually better to use path.expand().
normalizePath() is more drastic and can lead to paths the user will not
recognize on file systems with complex use of links.
R itself uses normalizePath() only where it needs to work hard to check that
paths are the same. One instance is .libPaths() (and it has led to puzzlement
there).
Thanks for the clarification.
In the case of WriteXLS, normalizePath() is used internally only, so the user
never sees the result of the function, unless they have 'verbose = TRUE', which
outputs a variety of status messages to the console, including the name of the
xls file created. I make the presumption that if they are specifying a more
complicated path prefix to the file, they have some sense of where the file
will end up.
There is some difference in the behavior of the two functions of course,
perhaps notably when using symlinks:
# On OSX for example, where /etc is a link to /private/etc:
path.expand("/etc")
[1] "/etc"
normalizePath("/etc")
[1] "/private/etc"
Would there be a scenario under which using normalizePath() would be less safe
than using path.expand(), if the user never really needs to see the expanded
path? Perhaps paths to external/network attached drives or something else that
I have not considered?
Not that I know of. normalizePath() should always give a valid path for
a valid input. But for example it might have characters in that the
using software did not expect (Mac OS 10.5 was fond of adding + and
space, and this could throw file:// URIs).
Regards,
Marc
A workaround for now, would be to wrap your filename in that function
in your code, so that when you use relative paths, the appropriate
expansion is used and passed to the gdata function as the filename
argument.
I just made this change myself in the WriteXLS package at the request
of another useR.
Regards,
Marc Schwartz
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
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.
