另一个免费、开源的Mac OS X v10.8 (Mountain Lion)首选项窗格/环境。plist解决方案是EnvPane。

EnvPane的源代码可在GitHub。EnvPane看起来具有与rcenvirenvironment相当的功能，然而，它似乎可以立即更新其存储的变量，即不需要重新启动或登录，这是受欢迎的。

如开发商所述:

EnvPane is a preference pane for Mac OS X 10.8 (Mountain Lion) that lets you set environment variables for all programs in both graphical and terminal sessions. Not only does it restore support for ~/.MacOSX/environment.plist in Mountain Lion, it also publishes your changes to the environment immediately, without the need to log out and back in. <SNIP> EnvPane includes (and automatically installs) a launchd agent that runs 1) early after login and 2) whenever the ~/.MacOSX/environment.plist changes. The agent reads ~/.MacOSX/environment.plist and exports the environment variables from that file to the current user's launchd instance via the same API that is used by launchctl setenv and launchctl unsetenv.

免责声明:我与开发者或他/她的项目没有任何关系。

附注:我喜欢这个名字(听起来像“Ends Pain”)。

/etc/launchd.conf在OS X v10.10 (Yosemite)、OS X v10.11 (El Capitan)、macOS v10.12 (Sierra)或macOS v10.13 (High Sierra)中不使用。

从launchctl手册页:

/etc/launchd.conf file is no longer consulted for subcommands to run during early boot time;
this functionality was removed for security considerations.

这个Ask Different answer中描述的方法适用于我(重启后):从Dock或Spotlight启动的应用程序继承了我在~/Library/LaunchAgents/my.startup.plist中设置的环境变量。(在我的例子中，我需要将LANG设置为en_US。UTF-8，用于Sublime Text插件。)

简单又快速地做了这个。首先创建一个~/。Bash_profile来自终端:

touch .bash_profile

then

open -a TextEdit.app .bash_profile

add

export TOMCAT_HOME=/Library/Tomcat/Home

保存文档，您就完成了。

任何Bash启动文件—~/。bashrc,(~ /。bash_profile、~ / . profile。还有一些奇怪的文件，名为~/. macosx /environment。用于GUI应用程序中的环境变量。

有时候，前面所有的答案都不适用。如果你想在Eclipse或IntelliJ IDEA中访问一个系统变量(如M2_HOME)，在这种情况下，唯一适合我的是:

首先(步骤1)编辑/etc/launchd.conf以包含如下一行:“setenv VAR value”，然后(步骤2)重新启动。

简单地修改.bash_profile将不起作用，因为在OS X中应用程序不会像在其他Unix中那样启动;它们不继承父函数的壳变量。其他的修改都不管用了，原因我也不知道。也许有人可以解释一下。

虽然这里的答案并不是“错误的”，但我还要补充一点:永远不要在OS X中改变影响“所有进程”的环境变量，甚至在shell之外，也不要影响给定用户交互运行的所有进程。

In my experience, global changes to environment variables like PATH for all processes are even more likely to break things on OS X than on Windows. Reason being, lots of OS X applications and other software (including, perhaps especially, components of the OS itself) rely on UNIX command-line tools under the hood, and assume the behavior of the versions of these tools provided with the system, and don't necessarily use absolute paths when doing so (similar comments apply to dynamically-loaded libraries and DYLD_* environment variables). Consider, for instance, that the highest-rated answers to various Stack Overflow questions about replacing OS X-supplied versions of interpreters like Python and Ruby generally say "don't do this."

OS X is really no different than other UNIX-like operating systems (e.g., Linux, FreeBSD, and Solaris) in this respect; the most likely reason Apple doesn't provide an easy way to do this is because it breaks things. To the extent Windows isn't as prone to these problems, it's due to two things: (1) Windows software doesn't tend to rely on command-line tools to the extent that UNIX software does, and (2) Microsoft has had such an extensive history of both "DLL hell" and security problems caused by changes that affect all processes that they've changed the behavior of dynamic loading in newer Windows versions to limit the impact of "global" configuration options like PATH.

不管“蹩脚”与否，如果您将这些更改限制在较小的范围内，您将拥有一个更加稳定的系统。