在OS X中修改环境变量如PATH的正确方法是什么?

我看了谷歌一点,找到了三个不同的文件进行编辑:

/etc/paths ~ / . profile ~ / tcshrc

我甚至没有这些文件中的一些,我很确定.tcshrc是错误的,因为OS X现在使用bash。这些变量,特别是PATH,定义在哪里?

我运行的是OS X v10.5 (Leopard)。


当前回答

在追逐环境变量首选项窗格后,发现链接已经损坏,在苹果网站上搜索似乎表明他们已经忘记了它……我开始回到难以捉摸的发射过程。

在我的系统(Mac OS X 10.6.8)上,似乎在环境中定义的变量。plist被可靠地导出到从Spotlight启动的应用程序(通过launchd)。我的问题是,这些变量没有被导出到终端中的新bash会话。也就是说,我的问题与这里描述的相反。

注:环境。如前所述,plist看起来像JSON,而不是XML

我可以通过编辑~/MacOSX/environment让Spotlight应用程序看到变量。plist和 我能够通过在我的.profile文件中添加以下内容将相同的vars强制到一个新的Terminal会话中:

eval $(launchctl export)

其他回答

就像Matt Curtis给出的答案一样,我通过launchctl设置环境变量,但我将它包装在一个名为export的函数中,因此每当我像在.bash_profile中一样导出一个变量时,它也由launchctl设置。我是这样做的:

My .bash_profile consists solely of one line, (This is just personal preference.) source .bashrc My .bashrc has this: function export() { builtin export "$@" if [[ ${#@} -eq 1 && "${@//[^=]/}" ]] then launchctl setenv "${@%%=*}" "${@#*=}" elif [[ ! "${@//[^ ]/}" ]] then launchctl setenv "${@}" "${!@}" fi } export -f export The above will overload the Bash builtin "export" and will export everything normally (you'll notice I export "export" with it!), then properly set them for OS X app environments via launchctl, whether you use any of the following: export LC_CTYPE=en_US.UTF-8 # ~$ launchctl getenv LC_CTYPE # en_US.UTF-8 PATH="/usr/local/bin:${PATH}" PATH="/usr/local/opt/coreutils/libexec/gnubin:${PATH}" export PATH # ~$ launchctl getenv PATH # /usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin export CXX_FLAGS="-mmacosx-version-min=10.9" # ~$ launchctl getenv CXX_FLAGS # -mmacosx-version-min=10.9 This way I don't have to send every variable to launchctl every time, and I can just have my .bash_profile / .bashrc set up the way I want. Open a terminal window, check out your environment variables you're interested in with launchctl getenv myVar, change something in your .bash_profile/.bashrc, close the terminal window and re-open it, check the variable again with launchctl, and voilá, it's changed. Again, like the other solutions for the post-Mountain Lion world, for any new environment variables to be available for apps, you need to launch or re-launch them after the change.

直到和包括OS X v10.7 (Lion),你可以设置它们:

~/.MacOSX/environment.plist

See:

https://developer.apple.com/legacy/library/qa/qa1067/_index.html https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html

对于终端中的PATH,您应该能够在.bash_profile或.profile中设置(尽管您可能必须创建它)

对于OS X v10.8 (Mountain Lion)及以上版本,您需要使用launchd和launchctl。

很简单:

编辑~ /。对变量进行配置并按如下方式放置

$ vim ~/.profile

在文件中放置:

MY_ENV_VAR =值

保存(:wq) 重启终端(退出并重新打开) 确保这一切都没问题:

$MY_ENV_VAR 美元的价值


要简洁明了地说明每个文件的用途

~ /。概要文件是每次终端源。App上线 ~ /。bashrc是“传统上”设置Bash环境的所有导出语句的地方 /etc/paths是Mac OS中的主文件,包含为所有用户构建PATH环境变量的默认路径列表 /etc/paths.D /包含包含其他搜索路径的文件

非终端程序不继承您的终端所继承的系统范围的PATH和MANPATH变量!要为特定用户启动的所有进程设置环境,从而使MacOSX GUI应用程序可以使用环境变量,这些变量必须在~/. macosx /environment中定义。plist (Apple Technical Q&A QA1067)

使用以下命令行同步您的环境。Plist /etc/paths:

defaults write $HOME/.MacOSX/environment PATH "$(tr '\n' ':' </etc/paths)"

虽然这里的答案并不是“错误的”,但我还要补充一点:永远不要在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.

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