Dirk Eddelbuettel wrote:
Well, first off, congrats for finding it :) Second, you didn't have too,
this is all documented in help(Startup) [ though I agree that finding
help is not always easy; OTOH doing help.search("Rprofile") would have
lead you there, along with some false positives ]
Thanks for the pointers! I already know about help() and help.search().
But the problem is, how is one supposed to know that 'Startup' is the
right help topic to request... And for help.search(Rprofile), in that
particular instance I was *searching* for the name of the file I needed
to edit for local customizations, so that wouldn't have worked very well
either. :-) (Yeah, I guess Startup is mentioned somewhere near the root
of the documentation. But in practice, when I'm looking for an answer to
a very specific question, I usually don't say to myself "Well, let's
start to read the documentation from the beginning.") Just to help to
put you in the mindset of someone who knows less about R than you do. ;-)
(And in practice, for that particular question, I find personally that
strace yields the answer in a way that's pleasingly consistently fast.
;-) But anyways, that's not the topic of this bug report...)
Third and most importantly, ?Startup says
Unless '--no-environ' was given on the command line, R searches
for site and user files to process for setting environment
variables. The name of the site file is the one pointed to by the
environment variable 'R_ENVIRON'; if this is unset or empty,
'R_HOME/etc/Renviron.site' is used (if it exists, which it does
not in a 'factory-fresh' installation). The user files searched
for are '.Renviron' in the current or in the user's home directory
(in that order). See 'Details' for how the files are read.
Then R searches for the site-wide startup profile unless the
command line option '--no-site-file' was given. The name of this
file is taken from the value of the 'R_PROFILE' environment
variable. If this variable is unset, the default is
'R_HOME/etc/Rprofile.site', which is used if it exists (which it
does not in a 'factory-fresh' installation). This code is sourced
into the 'base' package. Users need to be careful not to
unintentionally overwrite objects in 'base', and it is normally
advisable to use 'local' if code needs to be executed: see the
examples.
In both cases, Rprofile.site and Renviron.site are supposed to be empty!
That usually held me back from installing these.
Do you feel very strongly about having empty stubs? I'd prefer to just
leave things as they are; it's just one less thing that can break one day.
Well... ok, in order of decreasing "feeling very strongly about":
1. One thing I feel extremely strongly about is that as a sysadmin,
programs should never, ever require me to go edit something under /usr.
I reinstall the same list of packages on a new machine (or on the same
machine becaused of a hd that crashed), I should have the same,
identical /usr. If I edit a file under /usr, I'll end up forgetting that
I did, etc. Also, I really, really like being able to backup a small
/etc to get all the configuration of all the programs installed (< 50
MB), instead of having to backup a potentially much bigger (gigabytes)
/usr to catch the programs that put configuration files that might have
been edited at some point. In my mind (and I really doubt I'm the only
person thinking that way), for backups, disaster recovery, etc., /usr
(excluding /usr/local, of course) is completely handled by reinstalling
the set of .deb that were on the machine.
Consequently, I feel strongly (in a corresponding amount) in this case
about having the r-core-base package provide symlinks from
/usr/lib/R/etc to /etc/R for every file and directory that I might want
to create or edit to configure R. (Hey, you're the one who mentioned
"strong feelings" :-) ). As a sysadmin, I edit stuff under /etc... I can
install stuff under /usr/local, I can change stuff in /var from time to
time, but I never touch /usr, and never want to.
2. Once the symlinks are in /usr/lib/R/etc, I feel less strongly about
what files are in /etc/R. I'd still like you to consider installing
corresponding files in /etc/R, though, because from a
sysadmin-friendliness and discoverability point of view, I think it's
much better. You probably know R like the back of your hand, but let's
assume you know dhcp less well than R. Isn't it really nice to just
quickly browse around in /etc once you're installed dhcp and see at
least file with comments saying "here is the configuration file", so you
don't have to research that. (Not a great example, because the dhcp
config files will have a very specific format, while the R config files
will tend to be more R code, with no specific format). But I know that
in general, I find programs that put something under /etc much nicer and
sysadmin-friendlier (even if it's only a file with a small note as a
comment) than program that don't install the files in /etc and force you
to dig through the documentation to find the right file to create.
Since Rprofile is defined as being sourced from R, a file with only
comments should be guaranteed to be the same as an empty file (unless
they have a really weird definition of "comments" for a programming
language). And the note that you showed me from help(Startup) could be
put there as a comment, making it easier for relative R newbie sysadmins
to find their way around customizing R. But if you still feel really
uncomfortable about that, even an empty file in /etc/R would have been
better than nothing, because it gives a name to google (or
help.search()) about. So non-R expert sysadmins can go quickly from the
reflex (at least for me) of "I need to configure R, let's cd
/etc/Rsomething and look around to see what's there" to finding the
right file and getting the job done.
Thanks for considering this,
Christian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
