Skip to content

Failure of CLI with .Rprofile on Mac OS X

10 messages · Vincent Goulet, Gang Chen, David Winsemius +2 more

Original
Gang Chen
# 
When R starts in GUI on my Mac OS X 10.7.5, the startup configuration in .Rprofile works fine. However, when R starts through command line interface (CLI) on the terminal , it does not work at all. 

The GUI R on my Mac is aliased on the terminal to /Applications/R.app/Contents/MacOS/R while the CLI R (/usr/bin/R) is linked to /Library/Frameworks/R.framework/Resources/bin/R. There is only one .Rprofile, which resides in my home directory ~/.
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

What could be the cause for the failure with CLI?

Thanks,
Gang
Vincent Goulet
# 
You left out the part where you show us what's in your .Rprofile. If there is anything in there specific to R.app (an application different from R), of course it won't work with CLI ("base") R. 

Vincent Goulet
iPad
Gang Chen
# 
For testing purpose, there is only one statement in my .Rprofile

.First <- function() source('~/test.R')

and test.R contains a few functions with which I could test whether .Rprofile has been loaded or not.
David Winsemius
#
On Sep 19, 2014, at 2:01 PM, Gang Chen wrote:

            

      
      
      
    

        
Caveat: I'm not the best person to answer this. I'm not a skilled user of Unix and I'm not one of the Mac development team. But those guys are often not reading the mailing list on weekends so I thought I'd throw some ideas out that you could investigate.


#----- Idea # 1 ---------
Running 3.1.1 this is what I see among the environment variables that are different in a CLI session of R from those in a GUI session. In particular I am wondering if your PWD variable points to your User/username/ directory:

            

      
      
      
    

        
HOME                                  PWD 
             "/Users/davidwinsemius"              "/Users/davidwinsemius" 
                      XDG_CACHE_HOME                      XDG_CONFIG_HOME 
      "/Users/davidwinsemius/.cache"      "/Users/davidwinsemius/.config" 
                       XDG_DATA_HOME 
"/Users/davidwinsemius/.local/share" 

I haven't been able to find exactly what PWD is pointing to. It's not listed in the "environment variables" link from ?Sys.getenv. I think it's related tot eh Unix cli command `pwd` which prints the working directory. I don't know how to give you a direct link to the page with a listing of environment variables, since that page is one the doesn't conform to the convention of having a ?NameOfPage lookup. Its page name is "EnvVar" but ?EnvVar gives a "No documentation for ?EnvVar? ..." message. I also do not find "PWD" in a search of the Install/Admin document.

I tried changing PWD in a session an quitting, but it didn't seem to "stick".

            

      
      
      
    

        
PWD 
"/Users/davidwinsemius"

            

      
      
      
    

        
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.utf-8/en_US.utf-8/en_US.utf-8/C/en_US.utf-8/en_US.utf-8

attached base packages:
[1] grDevices datasets  splines   graphics  utils     stats     grid     
[8] methods   base     

other attached packages:
[1] rms_4.2-1       SparseM_1.03    Hmisc_3.14-4    Formula_1.1-1  
[5] survival_2.37-7 sos_1.3-8       brew_1.0-6      lattice_0.20-29

loaded via a namespace (and not attached):
 [1] cluster_1.15.2      latticeExtra_0.6-26 multcomp_1.3-1     
 [4] mvtnorm_0.9-9999    nlme_3.1-117        polspline_1.1.9    
 [7] quantreg_5.05       RColorBrewer_1.0-5  rpart_4.1-8        
[10] sandwich_2.3-0      zoo_1.7-11      

#---------- Idea # 2 --------

Another possibility is implied by this portion of the ?Startup page that (I already suggested you read):

"If you want ?~/.Renviron? or ?~/.Rprofile? to be ignored by child R processes (such as those run by R CMD check and R CMD build), set the appropriate environment variable R_ENVIRON_USER or R_PROFILE_USER to (if possible, which it is not on Windows) "" or to the name of a non-existent file."


#------ Suggestion -------------
So you need to check whether any of those are different than what you expect. Failing illumination after poking around in your setup,  I suspect you may need to post the output of ALL of sessionInfo() AND the results of dput(Sys.getenv()) .

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Notice that we have a similar, but unresolved, bug report a month old.

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15940

I assume that the obvious things like a .Rprofile in the current directory has been checked? 

Running R under a debugger, single-stepping through the startup code would likely isolate the trouble, but it's a bit of work to set up, and of course it needs to be on the machine that actually displays the problem.

-pd

        
On 20 Sep 2014, at 21:27 , David Winsemius <dwinsemius at comcast.net> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      David Winsemius
    

    

      
      #
    

  


  

      
On Sep 20, 2014, at 2:15 PM, peter dalgaard wrote:

        

            

      
      
      
    

        
Peter;

Do you know whether the "PWD" value in the result from  Sys.getenv() is supposed to point at the working directory of R started from the command line?

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
On 21 Sep 2014, at 01:25 , David Winsemius <dwinsemius at comcast.net> wrote:

        

            

      
      
      
    

        
Yes, that's standard Unix shell behavior:

Peter-Dalgaards-MacBook-Air:~ pd$ cd r-devel/BUILD 
Peter-Dalgaards-MacBook-Air:BUILD pd$ echo $PWD
/Users/pd/r-devel/BUILD

I.e. it is done by the shell, R just inherits it. Notice that it is just a variable tracking the result of 'cd'. You can set it, but that doesn't actually do anything, except for things that use the PWD variable directly, like the shell prompt

Peter-Dalgaards-MacBook-Air:BUILD pd$ export PWD=/foo/bar
Peter-Dalgaards-MacBook-Air:bar pd$ pwd
/Users/pd/r-devel/BUILD

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 21/09/2014 00:25, David Winsemius wrote:

            

      
      
      
    

        
There are too many variables here to say for certain.  The 'command 
line' is a shell, but the user can choose what that is.  (For 
Terminal.app, it is in the Startup preferences.)  The command 'cd' 
normally sets the environment variable PWD, but there are variants for 
different shells, and /usr/bin/cd which calls the builtin 'cd' in the 
current shell.  (The POSIX command 'pwd' can also set PWD, and that too 
can be a shell builtin.)

The user can also set PWD, both in the shell and from inside R.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
I suspected that I needed to put "more or less standard" in my reply...

Anyways, I think PWD is a red herring. Unless I'm confused (which has happened), the CLI on OS X is governed by src/unix/sys-unix.c and that has

attribute_hidden
FILE *R_OpenInitFile(void)
{
    char buf[PATH_MAX], *home, *p = getenv("R_PROFILE_USER");
    FILE *fp;

    fp = NULL;
    if (LoadInitFile) {
        if(p) {
            if(!*p) return NULL;  /* set to "" */
            return R_fopen(R_ExpandFileName(p), "r");
        }
        if((fp = R_fopen(".Rprofile", "r")))
            return fp;
        if((home = getenv("HOME")) == NULL)
            return NULL;
        snprintf(buf, PATH_MAX, "%s/.Rprofile", home);
        if((fp = R_fopen(buf, "r")))
            return fp;
    }
    return fp;
}

and $PWD doesn't factor into this. $HOME does, though. I can see three ways in which $HOME/.Rprofile might drop off the radar:

1) HOME set incorrectly
2) $HOME or $HOME/.Rprofile not readable according to permissions and ownership of R binary
3) path length overflow 

Neither seem particularly likely to me, but they should be relatively easy to check. (PATH_MAX on OS X seems to be 1024).

Something in the style of (NB, this zaps an existing ~/.Rprofile if you copy it literally)

$ echo 'Rprofile <- TRUE' >  ~/.Rprofile
$ R
...

            

      
      
      
    

        
[1] TRUE

            

      
      
      
    

        
-pd

        
On 21 Sep 2014, at 11:02 , Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

        

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Gang Chen
    

    

      
      #
    

  


  

      
Thanks all for chiming in!

Just tried the following:

            

      
      
      
    

        
ls -l $HOME/.Rprofile
-rw-r--r--  1 gangc  admin  17 Sep 21 07:10 /Users/gangc/.Rprofile

            

      
      
      
    

        
Less than 1024 characters.

            

      
      
      
    

        
In CLI R:

            

      
      
      
    

        
Rprofile <- TRUE

            

      
      
      
    

        
Error: object 'Rprofile' not found