On Nov 8, 2012, at 9:33 AM, Prof Brian Ripley <rip...@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 <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).
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
______________________________________________
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.
