[R] Absolute path in gdata library

[Marc Schwartz]

On Nov 8, 2012, at 9:33 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

> 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).


OK. Thanks!

Regards,

Marc


> 
> 
>> 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