OSX 10.10 "Yosemite" has a new "feature" whereby child processes started by popen() don't inherit their parents' PATH variables. This affects any process started by e.g. system or system2, as well as R system utilities such as Sys.which that work by invoking shell commands on Darwin.
This means that e.g. Sys.which() can't find items that are plainly in the path.
Nor can programs started via system or system2 see the path correctly.
> system("echo $PATH")
Some other breakage from around the web resulting from this change in behavior:
NB: This behavior is only present when R is used via a program started from the Dock (e.g. R.app); when R is started from the terminal (or is the child of any process started from the terminal), $PATH is inherited correctly.
Can you elaborate on the bug aspect? This is security feature where LS-started processes ignore PATH - it has nothing to do with R itself. Therefore Sys.which() is consistent - the PATH it is checking is in fact what will be used by system() and thus correct:
/bin/sh: pdflatex: command not found
Many packages and third-party apps rely on system() and system2() inheriting R's $PATH (cf. some of the TeX related packages linked above). At the very least, it's large difference in behavior between R.app and R at the console that requires developers to code for both cases in order to support OS X.
I have a lot of code that relies on the process started by `system()` inheriting the environment variables in the local environment. I think that's a much more robust approach than that of `system2()` which relies on pasting strings (and hence does not work on all platforms).
If you don't think this is behaviour is a bug, can you please describe how to work around it? i.e. how are we supposed to set the PATH for subprocesses?
Please refer to R-devel for discussion of this topic. This is a security feature that Apple has introduced and it affects PATH precisely to avoid the process from performing a search path injection. Other non-system environment variables are not affected. It is presumably aimed at making sure unqualified paths are not used for security reasons. Again, this is an OS decision and has nothing to do with R itself. I'm closing this with the note those interested can participate in the discussion on R-devel.
in the above comment, apologies
The evidence mounts that this is indeed a bug in Yosemite and not a security measure. Hence a work-around is now implemented.