How exactly is PATH calculated?

Question

I've read a dozen different answers and talked to a bunch of people and am having difficulty understanding how PATH is calculated in different scenarios. Specifically I'm thinking of

1. How exactly is PATH calculated for bash?
2. How exactly is it calculated for other shells? (I assume its shell dependent, but what is the commonality between all shells?)
3. How exactly is it calculated for GUI apps?
4. Am I missing another way of launching stuff? Do daemons do something different? (I don't think so? But maybe...)

Additionally I'm on High Sierra now but I'm seeing some people mentioned that this changed at some point?

I've seen this answer and this one but both seem to be focused explicitly on what happens inside of bash.

Answer 1

I'm going to lump together 1 & 2 because all shells read files at startup.

PATH is inherited from its parent process. This is a key concept that you need to understand.

The PATH is first hard coded into the kernel:

sysctl user.cs_path
user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin

launchd which acts as init can be configured to change this PATH. Generally it is not changed.

The loginwindow.app will setup an environment when you log into your computer. PATH will be checked that it has been set or it will be set to the hard coded path in the kernel or a modified path set by launchd. It is like the loginwindow.app is calling login -pf <username>.

At this point, a user LaunchAgent or LaunchDaemon may modify the PATH.

This will be the PATH available to GUI applications from the Finder. (Early versions of OS X could use ~/.MacOSX/environment.plist to change the PATH for GUI applications). Now if this seems complicated, it's not and more that likely,like me, the PATH available is /usr/bin:/bin:/usr/sbin:/sbin

When you start the Terminal.app, it first calls login (login -pf ) which triggers your shell to be treated as a login shell. The appropriate files in /etc and your HOME folder are read. Now, PATH should be different than set by the loginwindow.app. Remember we talked about inheritance? If you start a GUI app from within your terminal session then the PATH available to GUI application will be same as set by the shell.

As far as daemons, they are usually started by their absolute path.

Answer 2

From the man page for PATH (man path):

The search path for commands. It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below)....The default path is system-dependent, and is set by the administrator who installs bash. A common value is ``/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin''.

So, from that except from the bash man page, we see that the bash path is (initially):

• system dependent and not shell dependent
• set by the one who installed bash (in this case Apple)
• has a default value

The path can (obviously) be modified. There are several places where the PATH environment variable can be set:

• ~/.bashrc
• ~/.bash_profile

In macOS, the file /etc/paths is used to configure the search paths:

/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

Additionally, the path is initially configured by the /usr/libexec/path_helper utility which will create a path based on the contents of /etc/paths.d

It's called from /etc/profile which sets the system wide bash profile (individual ones are set in ~/.profile)

As for GUI apps, the shell path really has no effect. The only time a GUI application (Cocoa, Quartz, Metal) has anything to do with PATH is when it opens a shell (either interactive or non-interactive). At that point it will use the PATH environment as set or make whatever changes it needs at run time.

Different Shells

Each of the shells have a different system wide profile (as does bash) which set's the initial PATH (by calling the path_helper utility)

• Zsh = /etc/zprilfe
• Ksh = /etc/profile
• Csh = /etc/csh.login

Answer 3

All: Please understand that Apple has changed the Paths paradigm over time in Sierra (see https://lluad.com/blog/os-x-system-path/) , HighSierra, and Mojave. Path_helper now works somewhat differently it seems because it has locked up terminal windows for me that I can free and have working fine by commenting out

# if [ -x /usr/libexec/path_helper ]; then
#   eval `/usr/libexec/path_helper -s`
#  fi

in /etc/profile.

I have scripts that fix the path because I have several tools working, (the core of them is installed by Homebrew, but that is only about 15 of the 25 that I use every day) and these have to be set for use in .app applications, in .sh script startups, and for autolaunch in protected boot sequence under Mojave. It is confusing, but for sure Mojave has changed the structure required and I need to step it up myself.

What this means for this particular question is that the question is pertinent in all its breadth and that it needs to be answered by devs who have felt the pain and fixed their systems for Mojave, and also come from the various 'worlds' like normal IDE's, XCode, Eclipse, Bean, Intellij, etc. Also, those who depend upon homebrew stacks, or mamp stacks, etc. And for those who are doing docker, .node, vm, etc. work, and other deeper tools. As Apple implements greater security our stuff is going to break, but I am glad that Apple is doing their job. We need to do ours so we need leading edge folks to pass the new wisdom. Articles that are 6 or more months old are just going to confuse us.