Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
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
add comment

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?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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