path_helper e zsh

Question

Eu li que a Apple, em vez de encadernar mais e mais PATH variações de variáveis no final do arquivo de perfil de shell, criou path_helper binary para que pudesse expandir PATH variable automaticamente lendo listas de caminho de /etc/paths.d/ diretório.

Além disso, esse arquivo gera apenas a saída para csh e bash ( -c e -s flags de acordo). Não há saída para zsh (embora seja um pouco compatível com o bash - eu entendo isso).

Estou usando o zsh. Eu tenho o arquivo /etc/zshenv que contém as seguintes linhas:

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

Demora cerca de meio segundo quando abro o terminal ou a nova guia para que o processo seja concluído. Existe apenas um arquivo com caminho único ( /usr/X11/bin ). Quanto estou arriscando se eu remover /etc/zshenv ? Seria suficiente colocar o caminho mencionado acima em meus arquivos .zshrc ou .zshenv ?

    

Answer 1

Have você viu isso, superuser.com em um problema semelhante? O blog post diz (e cito quase o post completo):

/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.

A discussão também inclui um link para uma substituição escrita em Perl, github.com/mgprot/path_helper (não tem idéia sobre sua velocidade, tho) .

Editar: A partir dos comentários da postagem do blog acima mencionados - um patch para path_helper que deve ser outra maneira de corrigir o problema.

    

Answer 2

Eu sei o que segue não tem impacto na velocidade de iniciar um novo terminal. No entanto, ele me mordeu, então pensei em colocar meus dois centavos.

Eu acho que é realmente questionável que esta chamada (para path_helper) esteja em zshenv (que é chamada para todos os shells, não apenas shells de login). Para outras shells, a chamada path_helper está em / etc / profile ou em /etc/csh.login - que são chamadas apenas para shells de login.

Isso se torna um problema se você executar o utilitário 'screen' em zsh. 'screen' não iniciará um shell de login, mas herdará o ambiente do shell de chamada. Mas ainda vai chamar o / etc / zshenv e bu extension path_helper.

Por acaso, o path_helper não apenas pega candidatos do PATH de /etc/paths.d, mas se existe um PATH quando é chamado, ele manipulará ativamente este PATH - ele removerá os componentes encontrados em / etc / paths e /etc/paths.d e prefixá-los. Assim, se você colocar $ {USER} / bin ou / usr / local / bin na cabeça do PATH (porque você quer que seus próprios programas sejam encontrados primeiro), então isto não funcionará dentro de uma sessão de 'tela'.

Minha correção sugerida para meu próprio problema é renomear / etc / zshenv para / etc / zprofile (atualmente inexistente), mas estou preocupado que isso tenha efeitos negativos ... pode ser uma razão pela qual a implementação do zsh no OS X tem essa chamada em / etc / zshenv, e com certeza ele será quebrado quando o próximo sistema operacional for lançado e eu esquecerei tudo sobre a minha correção.

Alguém viu isso? Ou tem algum pensamento?