On Mon, 9 Apr 2001, Kurt Hornik wrote:
OK! if you put it like that, then I think that .First should
definitely > *not* be used for package set-up, as it prevents
.Rprofile commands from > being the last things executed before the
prompt, and thus removes > "complete user control" of the set-up.
Not sure if I understand this.
Upon startup,
* Then, unless `--no-init-file' was given, R searches for a file
called `.Rprofile' in the current directory or in the user's home
directory (in that order) and sources it.
* It also loads a saved image from `.RData' if there is one (unless
`--no-restore' or `--no-restore-data' was specified).
* Finally, if a function `.First' exists, it is executed. This
function (as well as `.Last' which is executed at the end of the R
session) can be defined in the appropriate startup profiles, or
reside in `.RData'.
as per R-intro, so the user has perfect control over what happens by
providing a suitable .First in e.g. his ~/.Rprofile.
You are right -- I was discounting the "inelegant" use of an empty
.First in .Rprofile to mask the one defined in the global environment.
I have approached this in terms of preventing an unwanted package from
being loaded, but I can see the advantages of using a .First
definition in the user's .Rprofile to explicitly load packages as
well. I guess my worry would be that as the core of R gets smaller
and more packages are added to the default list it would be simpler
for the user to remove the one or two packages that are not wanted,
rather than having to specify explicitly in a .First all the packages
that are required, as would be the case currently.