[R] Absolute path in gdata library

[Prof Brian Ripley]

On 08/11/2012 15:28, Marc Schwartz wrote:
>
> On Nov 8, 2012, at 12:57 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
>
>> On 07/11/2012 23:12, Marc Schwartz wrote:
>>> On Nov 7, 2012, at 4:58 PM, r <ric.romoli at 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,                  ripley at 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