Execute function at startup
On Wed, 14 Apr 2004 09:17:56 +1000, <Mark.Bravington@csiro.au> wrote :
I think you can already do this via .First(). If you start your .First with something like this [give or take some parentheses] if( !is.null( runfirst <- Sys.getenv( 'RUNFIRST'))) try( eval( parse( text=runfirst))))
I forget whether Erich mentioned it in this post, but in other messages he's told me that the intention is to use this as a way to start R for naive users, immediately firing up Rcmdr for instance. It's possible to install a .First function for such users, but it would be easier if the capability was built in.
[And I reiterate the suggestion that .First should run immediately before giving control to the user-- perhaps unlike .Rprofile-- rather than before packages are loaded.]
I think you're right about this.
As a general comment-- not just on this case-- I think there are dangers in allowing R to accrue too many new alternative ways of doing the same thing. My own experience is that "or you can do it this way" improvements in usability tend to be minor, and are more than outweighed by making R harder to learn-- and also harder to teach-- because people get mixed messages. In this specific case, what with .Rprofile, .First, .First.sys, environment variables, autoload lists, hooks, .onLoad, .onAttach, .First.lib, etc, there are already heaps of places to put "extra stuff"-- some might think too many. Just my 2c's worth, anyway
I don't think it's really that bad: a lot of those are things of interest only to package writers. Users only need to worry about Rprofile.site .Rprofile (which are sourced in that order), just before .Rdata is loaded. Then the functions .First base::.First.sys are executed. I think the main thing wrong with the current scheme is that those last two functions are in the wrong order: the user-defined .First should come last. Adding one more thing to the list (executing a command specified on the command line) seems reasonable to me. Duncan Murdoch