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 <[email protected]> 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 <[email protected]> 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, [email protected]
> 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: [email protected] Priv: [email protected]
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
