Mac OS X Lion no longer recognizes environment.plist?

Question

Just installed Lion today and my PATH env variable is no longer being set by ~/.MacOSX/environment.plist. Did something change? Can't seem to find any info on that or how to fix. Any ideas?

Here's the contents of the PLIST:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PATH</key>
    <string>/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/X11/bin:/Users/mdi/bin</string>
</dict>
</plist>

score 15 · Answer 1 · answered Jul 22 '11 at 16:53

15

I ran into the same issue today. I called Apple Support and after being escalated to a Senior Advisor, then to her supervisor, I was told that they no longer support environment.plist and that there is no officially-supported method for defining environment variables in Mac OS 10.7.

answered Jul 22 '11 at 16:53

sworisbreathing

670
4
16

2

environment.plist working perfectly well here with Lion, and it's still referenced in Apple's developer docs: http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html#//apple_ref/doc/uid/20002093-BCIJIJBH . I'm always very suspicious of things supposedly said by "some guy at Apple Support". – mluisbrown Oct 18 '11 at 11:40
I am suspicious as well, especially since the support people were not even aware of `environment.plist` in the first place (hence the escalation to the senior advisor's supervisor). However, the developer documentation listed above is dated 2009, and the latest version of XCode does not appear to include the Property List Editor app anymore (although I did find the one in my old developer tools folder). If it's working on your system, can you tell me what the permissions are on it? Mine are `-rw-r--r--@`, and the file belongs to my user and group (as in, the group whose name is my username) – sworisbreathing Oct 24 '11 at 16:20

score 14 · Accepted Answer · edited May 23 '17 at 11:52

14

Use ~/.launchd.conf instead (see man launchctl).

See this answer for details.

edited May 23 '17 at 11:52

Community

1
1

answered Jul 21 '11 at 03:13

LaC

12,624
5
39
38

2

Actually I take that back. It is working but it is NOT setting my PATH in a shell. So if I set the path in `~/.launchd.conf` and `~/.bash_profile` everything is back to normal. Thanks! – Michael Irwin Jul 21 '11 at 09:10
Actually, I spoke too soon again. This does not set PATH for GUI apps. I've tried all sorts of things to get this to work and nothing seems to do it. Giving up for now... – Michael Irwin Jul 22 '11 at 17:44
1

~/.launchd.conf is not read on login or startup. this only works if I run `cat ~/.launchd.conf | launchctl` in Terminal. When I look at man launchd.conf in Lion 10.7.3 it says: $HOME/.launchd.conf Your launchd configuration file (currently unsupported) – uncreative Apr 10 '12 at 22:44
Quote from the manual: While it was documented that `$HOME/.launchd.conf` would be consulted prior to setting up a user's session, this functionality was never implemented. – Simba Oct 18 '21 at 08:16

score 10 · Answer 3 · answered Dec 07 '11 at 20:19

Whether or not Apple officially supports this mechanism, the current tech note Technical Q&A QA1067 is still accurate. An important caveat, however, is absent: the Property List needs to be in binary format. Xcode 4, when used to create new Property Lists, emits files that are in the text format (regardless of the type specified in File Inspector). So you either need to convert the saved file using 'plutil':

plutil -convert binary1 environment.plist

or use 'defaults' to write out a new, template file that you can edit in Xcode (which will honor the original binary format when saving):

defaults write defaults write $HOME/.MacOSX/environment Root "1"

The referenced document is now listed as "Retired" on developer.apple.com. — Dorrin, Sep 20 '13 at 17:41

score 1 · Answer 4 · answered Apr 09 '12 at 11:24

1

Do it like brew and create a symlink in /usr/local/bin/. Works perfectly for me and is IMO a more unix-like solution where everything is a file.

answered Apr 09 '12 at 11:24

Programmer

11
1

score 1 · Answer 5 · answered Oct 12 '12 at 18:06

I just got burned by something similar in Snow Leopard, and then figured out what the problem was.

I was doing:

$ cd
$ defaults write .MacOSX/environment FOO bar

...but it turns out that this is different from doing (in my case):

$ cd
$ defaults write /Users/ljnelson/.MacOSX/environment FOO bar

That is, the "path" (it's not really a path) to your domain must be the full file path to your $HOME/.MacOSX/environment.plist file (minus the .plist suffix). Anything else will write variables to a different domain (no idea where it got put), apparently.

So, upshot: always do defaults write /full/path/to/your/.MacOSX/environment VARNAME value; don't use any shortcuts at all for the first argument to the write subcommand.

score 1 · Answer 6 · answered Aug 02 '11 at 10:55

Weird, cause here it works flawlessly. I had to setup a JRI environment to access R internals from a Java applications, and updating the .profile was not enough to have NetBeans catching all env vars.

Creating the environment.plist file did the the trick.

For reference this the file's content:

Malessere:~ xxxxx$ cat .MacOSX/environment.plist 
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
   <dict>
      <key>DYLD_LIBRARY_PATH</key>
      <string>/Users/xxxxx/lib/jri-2.13</string>
      <key>R_HOME</key>
      <string>/Library/Frameworks/R.framework/Resources</string>
   </dict>
   </plist>

Hmm, does that really start with three spaces? If so, that's not right: XML declarations are required to be at the very beginning of the file (except for a possible BOM). — SamB, Oct 04 '12 at 18:45

score 1 · Answer 7 · answered Sep 21 '22 at 18:52

The modern way to set environment variables for all processes launched by the current UI user is by having a launch agent.

Using an example from the AutoDesk documentation, create a file at ~/Library/LaunchAgents/environment.plist (can use any filename) with the following content:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
<dict>
    <key>Label</key>
    <string>my.startup</string>
    <key>ProgramArguments</key>
    <array>
    <string>sh</string>
    <string>-c</string>
    <string>launchctl setenv RV_OS_PATH_OSX /volumes/zdisk;
launchctl setenv RV_OS_PATH_WINDOWS Z:;</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

score 0 · Answer 8 · answered Jul 18 '12 at 14:55

0

By default, Mac OS X (10.7.4 and up) does not support it any more. See http://support.apple.com/kb/TS4267

answered Jul 18 '12 at 14:55

mac joost

357
2
3

That's referring to those environment variables that the dynamic loader uses, not to all environment variables. They probably changed the dynamic loader to make it harder to spoof it into loading arbitrary code, which could be malicious code, into processes. – Nov 29 '12 at 20:58

score 0 · Answer 9 · answered Sep 02 '12 at 21:49

[[I'm copying this answer of mine into here, because it just may be helpful to someone:]]

Due to my own explorations, I now know how to set environment variables in 7 of 8 different ways. I was trying to get an envar through to an application I'm developing under Xcode. I set "tracer" envars using these different methods to tell me which ones get it into the scope of my application. From the below, you can see that editing the "scheme" in Xcode to add arguments works, as does "putenv". What didn't set it in that scope: ~/.MACOS/environment.plist, app-specific plist, .profile, and adding a build phase to run a custom script (I found another way in Xcode [at least] to set one but forgot what I called the tracer and can't find it now; maybe it's on another machine....)

GPU_DUMP_DEVICE_KERNEL is 3

GPU_DUMP_TRK_ENVPLIST is (null)

GPU_DUMP_TRK_APPPLIST is (null)

GPU_DUMP_TRK_DOTPROFILE is (null)

GPU_DUMP_TRK_RUNSCRIPT is (null)

GPU_DUMP_TRK_SCHARGS is 1

GPU_DUMP_TRK_PUTENV is 1

... on the other hand, if I go into Terminal and say "set", it seems the only one it gets is the one from .profile (I would have thought it would pick up environment.plist also, and I'm sure that once I did see a second tracer envar in Terminal, so something's probably gone wonky since then; long day....)

score 0 · Answer 10 · answered Apr 14 '18 at 04:15

I recently packaged up tools used by Xcode's Run Script Phase and placed them in $HOME/bin. My bash shell's PATH environment variable included this, so I assumed the Xcode would too.

It never worked and I found issues like the one here.

I printed the PATH variable from the script (echo $PATH) called by Xcode to see what the PATH variable was set to.

Fortunately, one of those paths, /Applications/Xcode.app/Contents/Developer/usr/local/bin was never used.

Here was my solution. I created a symbolic link from the above directory to $HOME/bin.

Navigate to /Applications/Xcode.app/Contents/Developer/usr/local and execute sudo ln -s $HOME/bin bin.

My tools were now available to the Xcode platform.

score 0 · Answer 11 · edited Sep 29 '12 at 22:52

0

You can edit your ~/.MacOSX/environment.plist with this example of $PATH:

defaults write $HOME/.MacOSX/environment PATH "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/opt/local/bin"

This will rewrite your ~/.MacOSX/environment.plist

or edit this file:

/etc/paths

to change the order of system variables.

edited Sep 29 '12 at 22:52

Brad Larson

170,088
45
397
571

answered Jan 20 '12 at 17:47

gylow

1

Mac OS X Lion no longer recognizes environment.plist?

11 Answers11

Linked