From lgautier at gmail.com  Mon Dec  1 11:38:21 2008
From: lgautier at gmail.com (Laurent Gautier)
Date: Mon, 01 Dec 2008 11:38:21 +0100
Subject: [Rd] unrelated software install triggering an error from R's
 install script on Mac OS X 10.5
In-Reply-To: <4FC00087-A387-48CA-88EB-5823AE70BF85@r-project.org>
References: <49315329.7050703@gmail.com>
	<5EF06ADB-867B-4151-BBD2-E8293BE42745@uos.de>
	<49330FA2.1030604@gmail.com>
	<4FC00087-A387-48CA-88EB-5823AE70BF85@r-project.org>
Message-ID: <4933BE9D.1080204@gmail.com>

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



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