[R-SIG-Mac] Failure of CLI with .Rprofile on Mac OS X

[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
...
> Rprofile
[1] TRUE
> file.show(paste(Sys.getenv("HOME"),".Rprofile", sep="/"))


-pd 

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

> On 21/09/2014 00:25, David Winsemius wrote:
>> 
>> On Sep 20, 2014, at 2:15 PM, peter dalgaard wrote:
>> 
>>> 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:
>>> 
>>>>> 
>>>>> snipped
>> 
>>>> 
>>>> 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.
>> 
>> 
>> 
>>>> 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[sic] Unix cli command `pwd` which prints the working directory.
>> 
>> 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?
>> 
> 
> 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.
> 
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> 1 South Parks Road, Oxford OX1 3TG, UK

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com