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?
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
______________________________________________
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.
