[R-SIG-Mac] .First for R.app called twice?

[Simon Urbanek]

On May 16, 2012, at 1:10 PM, R. Michael Weylandt wrote:

> Suppose I have the following very simple ~/.Rprofile
> 
> .First <- function(){
>    assign("e", exp(1), .GlobalEnv)
>    lockBinding("e", .GlobalEnv)
> }
> 
> If I start R from the terminal, all is fine, but if I use R.app this
> throws an error about not being able to change the assigned value of a
> locked binding on "e". This makes me think that R.app hits .First()
> twice -- is that the intended behavior? [You can demonstrate this with
> cat() statements more directly, but I figured I'd show a use case]
> 
> I don't have access to another computer right now to confirm, but the
> difference between Terminal and R.app seems funny. If it seems to be a
> problem with my machine, I'll hunt further.
> 

It is somewhere between intention and a bug. It is caused by the necessity of the R.app GUI to deal with launches in a different working directory -- e.g. when you drag a folder on the GUI. Because the GUI has to setup R and start the event loop before it can accept open events it emulates the regular R behavior after receiving the open event by starting R with --no-restore-data first and then loading the workspace "by hand" and running .First(). This is all fine if you use your workspace to populate .First, but if you do that in .Renviron then .First gets called twice: first when R starts without a workspace and then by the GUI because it doesn't know that your .First does not come from the loaded workspace. 

Obviously, an easy work-around is to check with bindingIsLocked().

That said, I have added a very, very ugly hack to work around your case in the GUI.

Cheers,
Simon