path_helper and zsh

Question

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`
fi

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?

Answer 1

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.

Answer 2

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?