[R] detecting the sourcing of site profile on Startup versus post-Startup

[Benjamin Tyner]

Jeff,

I absolutely agree it is a bad idea to rely on side effects.

I did figure out one way to skin this cat. It relies on an the following
from line 909 of src/main/main.c,

    R_LoadProfile(R_OpenSiteFile(), baseEnv);
    R_LockBinding(install(".Library.site"), R_BaseEnv);
    R_LoadProfile(R_OpenInitFile(), R_GlobalEnv);

to illustrate, if one puts at the top of the site profile:

   if (bindingIsLocked(".Library.site", .BaseNamespaceEnv)) {
      # site profile has already finished loading;
      # put code here for that case. for example,
      if (identical(.BaseNamespaceEnv$.GoodJob, Sys.getpid())) {
          warning("you appear to be using the same file for both site
and user profiles, or to have sourced this file post-startup.")
      }
      warning("this file is not intended to be used in this fashion.")
   } else {
      # site profile is in process of loading;
      # put code here for that case. for example,
      message("good job! startup loaded the correct site profile.")
      .GoodJob <- Sys.getpid()
   }

Not exactly best practice to rely on an implementation detail, but I
found it interesting nevertheless.

Regards
Ben


On 04/23/2014 09:31 PM, Jeff Newmiller wrote:
> Regardless of whether this is possible, it seems like a bad idea (side effects in a functional programming environment). If you want to do something special in startup then write a different function that does that stuff and then call the desired functions explicitly when you want them to be called.
> ---------------------------------------------------------------------------
> Jeff Newmiller                        The     .....       .....  Go Live...
> DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
>                                       Live:   OO#.. Dead: OO#..  Playing
> Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
> /Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
> --------------------------------------------------------------------------- 
> Sent from my phone. Please excuse my brevity.
>
> On April 23, 2014 6:11:09 PM PDT, Benjamin Tyner <btyner at gmail.com> wrote:
>> Thanks  Duncan!  Yes, I considered taking advantage of .First, but was
>> concerned that the .First defined by the site profile could be masked
>> by a
>> possible .First defined by the user profile (I neglected to mention
>> that
>> "--no-init-profile"  [sic]  in  the  example  I gave was a simplifying
>>   assumption, sorry about that).
>>   On 04/23/2014 06:55 AM, Duncan Murdoch wrote:
>>
>>     On 22/04/2014, 8:59 PM, Benjamin Tyner wrote:
>>
>>     Greetings,
>> Is there any way to programmatically detect whether a piece of code is
>>   being run within the initial (Startup) sourcing of the site profile?
>>   For example, say I have a site profile, "/path/to/Rprofile.site". Is
>>   there any function "my_func" which would return different values for
>>     these two instances:
>>         Rscript --no-site-profile --no-init-profile -e
>>    "sys.source('/path/to/Rprofile.site',  envir  = .BaseNamespaceEnv);
>>     my_func()"
>>     versus:
>>         export R_PROFILE=/path/to/Rprofile.site
>>         Rscript --no-init-profile -e "my_func()"
>>
>> The commandArgs() function could see the different command lines and
>> your
>>     function could deduce the difference from that.
>> As far as I know, R keeps no other records of the startup process, but
>> if
>> you can modify other files, you could leave a record when .First was
>> run,
>>    and see that it was run before Rprofile.site in the first case. See
>>     ?Startup.
>>     Duncan Murdoch
>>
>>   --
>>   
>>
>>
>> ------------------------------------------------------------------------
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.


-- 
//