I read that Apple, instead of jamming more and more PATH variable variations to the end of shell profile file, created path_helper binary so that it could expand PATH variable automatically by reading path lists from /etc/paths.d/ directory.

Also - this file generates output only for csh and bash (-c and -s flags accordingly). There is no output for zsh (although zsh being somewhat bash compatible - I understand that).

I am using zsh. I have /etc/zshenv file which contains following lines:

# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`

It takes about half a second when I open terminal or its new tab for that process to complete. There is only one file with single path (/usr/X11/bin). How much am I risking if I remove /etc/zshenv at all? Would it be enough to put aforementioned path to my .zshrc or .zshenv files?

  • Are you sure the half second (which I believe really is annoying) is due to this path_helper call? I suspect it could just be zshs start-up time, bash takes a moment, too. While adding PATH entries in the usual way should do the same job, I doubt a little path_helper needs that much longer. (Easy test: setopt noglobalrcs in ~/.zshenv)
    – sr_
    Oct 20 '11 at 9:14
  • @sr_ - yes, I can see the process title in the terminal window's titlebar or tab itself.
    – Eimantas
    Oct 20 '11 at 9:47

Have you seen this, superuser.com on a similar issue? The linked blog post says (and I quote almost the complete post):

/usr/libexec/path_helper, which Mac OS X runs every time a login shell is created, is really slow. (In particular, I think the slowness is in [[ "$NEWPATH" = *(*:)${p}*(:*) ]].) My Terminal windows were taking about four seconds to open. By removing the files in /etc/paths.d and putting their contents directly into my $PATH in .bash_profile, Terminal windows now load instantly.

The discussion also includes a link to a replacement written in Perl, github.com/mgprot/path_helper (no idea about its speed, tho).

Edit: From the aforementioned blog post's comments - a patch to path_helper that should be another way to fix the issue.

  • 1
    Thanks for your reply! AFAIK, the path_helper on my system is actual universal binary (for i386 and x64_86 architectures). So I'm not sure the patch will help me. Although now at least I'm confident enough to remove all the files from /etc/paths.d/
    – Eimantas
    Oct 20 '11 at 12:56
  • I have just removed all files from /etc/paths.d/ and terminal starts instantly (after rebooting to ensure no warm startup)!
    – Eimantas
    Oct 20 '11 at 12:59

I know what's following has no impact on the speed of starting a new terminal. However it's bitten me so I thought I'd put in my two cents.

I think it's actually questionable that this call (to path_helper) is in zshenv (which is called for all shells, not just login shells). For other shells the path_helper call is instead in /etc/profile or in /etc/csh.login -- which are called only for login shells.

This becomes a problem if you run the 'screen' utility under zsh. 'screen' will not start a login shell, but will rather inherit environment from the calling shell. But it will still call /etc/zshenv and bu extension path_helper.

As it happens, path_helper will not only grab PATH candidates from /etc/paths.d, but if there is an existing PATH when it's called, it will actively manipulate this PATH -- it will strip out components that it found in /etc/paths and /etc/paths.d and prepend them. Thus if you have put ${USER}/bin or /usr/local/bin at the head of PATH (because you want your own programs to be found first) then this will not work inside a 'screen' session.

My suggested fix to my own problem is to rename /etc/zshenv to /etc/zprofile (currently nonexistent) but I'm worried that this will have ill effects... there might be a reason why the zsh implementation on OS X has this call in /etc/zshenv, and it will for sure be broken when the next OS comes out and I will have forgotten all about my fix.

Anyone else seen this? Or have any thoughts?

  • I'm not sure you're right about PATH being manipulated. I think I've always been able to put what I want at the head of PATH. Then again, I generally do that in my .zshrc file, after path_helper has already done its work. Feb 23 '15 at 21:28
  • 2
    @MarnenLaibow-Koser I know this answer is ancient, but it seems that in OSX El Capitan the call to path_helper has been moved from /etc/zshenv to /etc/zprofile May 25 '16 at 17:00
  • 1
    Yeah, this is an extremely stupid thing to do. Lost countless of hours debugging why a makefile doesn't work when zsh is used as the shell?! Guess what - the PATH was always reset so that the commands were executed from wrong locations. If you have this piece of ... in zshenv better to remove it asap and/or move to /etc/zprofile. Nov 6 '17 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.