Bug 16042 - OSX 10.10 Yosemite: child processes don't inherit PATH (breaks Sys.which et al.)
Summary: OSX 10.10 Yosemite: child processes don't inherit PATH (breaks Sys.which et al.)
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: Mac GUI / Mac specific (show other bugs)
Version: R 3.1.1
Hardware: Other Other
: P5 normal
Assignee: Simon Urbanek
URL:
Depends on:
Blocks:
 
Reported: 2014-10-23 18:24 UTC by Jonathan
Modified: 2015-12-14 13:45 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan 2014-10-23 18:24:29 UTC
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.

> Sys.getenv("PATH")
[1] "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/git/bin:/usr/texbin"
> file.exists("/usr/texbin/pdflatex")
[1] TRUE
> Sys.which("pdflatex")
pdflatex 
      "" 

Nor can programs started via system or system2 see the path correctly.

> system("echo $PATH")
/usr/bin:/bin:/usr/sbin:/sbin

Some other breakage from around the web resulting from this change in behavior:
http://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
https://github.com/atom/atom-shell/issues/550

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.
Comment 1 Simon Urbanek 2014-10-23 19:00:44 UTC
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:

> Sys.which("pdflatex")
pdflatex 
      "" 
> system("pdflatex")
/bin/sh: pdflatex: command not found
Comment 2 Jonathan 2014-10-24 17:18:12 UTC
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.
Comment 3 Hadley Wickham 2014-10-24 17:23:19 UTC
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?
Comment 4 Simon Urbanek 2014-10-24 17:58:04 UTC
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.
Comment 5 Simon Urbanek 2014-10-24 17:59:21 UTC
s/R-devel/R-SIG-Mac/g
in the above comment, apologies
Comment 6 Simon Urbanek 2014-10-30 16:14:24 UTC
The evidence mounts that this is indeed a bug in Yosemite and not a security measure. Hence a work-around is now implemented.