[Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5

[Simon Urbanek]

On Dec 1, 2008, at 6:38 PM, Laurent Gautier wrote:

> Simon Urbanek wrote:
>> On Dec 1, 2008, at 6:11 AM, Laurent Gautier wrote:
>>> Stefan Evert wrote:
>>>>> The steps needed to generate the error are:
>>>>>
>>>>> - install a binary distribution of R (default location)
>>>>> - add R to the PATH
>>>> Did you actually add
>>>>   /Library/Frameworks/R.framework/Resources/bin/
>>>> to your PATH?  You're not supposed to do that!  What made you  
>>>> think so?
>>>
>>> Coming from an UNIX background, adding a directory like bin/ to  
>>> the PATH   does not appear unreasonable.
>>>
>> ... if you really want those files to prepend your PATH. You get  
>> what you deserve ;) I this case you don't want that and this is  
>> true for all unix platforms.
>
> The point seems to be slightly missed here: the result of installing  
> R is that there is no R executable in the path,


Clearly a false statement, look in /usr/bin (both R and Rscript are  
installed there) - hence there is no need for you to add anything ...  
which is why I think this discussion is quite redundant ;).

Cheers,
S


> and that adding the only bin/ directory coming with the install to  
> be path results in a broken system.
>
>
>
>
>>>> This directory contains a range of support scripts for R which  
>>>> are not intended for direct use from the command line or other  
>>>> programs.  In my installation, there's just a symlink from /usr/ 
>>>> bin/R to the R binary in the directory above, which AFAIK is the  
>>>> only program you need to invoke directly.
>>>
>>> I am relatively new to OS X, so I cannot tell whether this is an R  
>>> specificity, or the way things are usually done on OS X are  
>>> somewhat very different from the UNIX way.
>> Then you seem to be very unfamiliar with the unix way as it  
>> appears...
>
> Ah ! the flourishing pronouncements on the R-lists...
>
>
>>> I am surprised by this cherry pick one executable in bin/ / don't  
>>> touch the PATH.
>>>
>> You are apparently unaware of the way R is setup ... Note that on  
>> most unix systems this is exactly what you get - the R_HOME/bin  
>> directory is tucked away in /usr/local/lib/R/bin which is never on  
>> your PATH since R installs the user-visible scripts to /usr/local/ 
>> bin. The same happens here.
>
> I guess that we this comparing apples with oranges here:
> a default R install is leaving binaries in the path when performing  
> a default install, which does not seem to be the case here  
> (therefore forcing a hunt for the executable for the R console and  
> resulting in the present thread).
>
> The point here is that there is no user-exposed bin/ directory (or  
> copying of the "right" executables by default to a place commonly  
> agreed by some UNIX audiences as proper for binaries), and that the  
> only bin/ found contains executables one should not get in his/her  
> PATH.
>
>
>>>
>>>> In your case, R's "INSTALL" script, which implements the "R CMD  
>>>> INSTALL" functionality masks the standard "install" program in / 
>>>> usr/bin/install, so Python's installer now picks up a completely  
>>>> wrong program.  Even if you edit R's "INSTALL" script, it'll do  
>>>> something entirely different from what you expect.
>>>
>>> To my great dismay I am hearing here that Mac OS X is not case- 
>>> sensitive.
>>>
>> Mac OS X is case-sensitive. Case-sensitivity is an option of the  
>> mounted file system and you can choose either. It is common to use  
>> case-insensitive fs for historical reasons (compatibility with  
>> older software), but you don't have to.
>
>
>
>>>> BTW, putting the R binary directory ahead of system directories  
>>>> such as /usr/bin in your PATH is an even worse idea than  
>>>> including it there in the first place. ;-)
>>>
>>> I am used to the fact that adding a bin/ directory in the PATH  
>>> (and *ahead* of all other components in the PATH) is the way to  
>>> add custom binaries.
>> If you want to override the system ones, yes. But you better know  
>> what you're doing ;).
>>> I cannot exclude that I am missing some specificities of Mac OS X,  
>>> but that idea seems to be at least shared by the fink project  
>>> (their default install puts /sw/bin ahead of all the rest).
>>>
>> .. which leads to quite a few problems on its own. That's why  
>> you're entirely on your own if you do so (and likely to run into  
>> problems where Fink replaces systems parts with non-standard  
>> binaries).
>>> I suppose that there is a documentation for R-on-OS-X and that I  
>>> overlooked it.
>>>
>> You overlooked quite a bit of documentation of unix and R - pretty  
>> much none of it is OS X - specific.
>> Cheers,
>> S
>>>
>
>