path_helper и zsh

Я прочитал, что Apple, вместо того, чтобы больше и больше изменять переменные PATH до конца файла профиля оболочки, создал двоичный файл path_helper чтобы он мог автоматически расширять PATH , читая списки путей из /etc/paths.d/ .

Также – этот файл генерирует выходные данные только для csh и bash (соответственно -c и -s ). Для zsh нет выхода (хотя zsh является несколько совместимым с bash – я это понимаю).

Я использую zsh. У меня есть файл /etc/zshenv который содержит следующие строки:

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

Это займет около полутора секунд, когда я открываю терминал или его новую вкладку для завершения этого процесса. Существует только один файл с единственным путем ( /usr/X11/bin ). Насколько я рискую, если вообще удалю /etc/zshenv ? Было бы достаточно поставить вышеупомянутый путь к моим .zshrc или .zshenv ?

Вы видели это, superuser.com, по аналогичной проблеме? Связанное сообщение в блоге говорит (и я цитирую почти полный пост):

/usr/libexec/path_helper , который Mac OS X запускается каждый раз, когда создается оболочка входа, выполняется очень медленно. (В частности, я думаю, что медлительность находится в [[ "$NEWPATH" = *(*:)${p}*(:*) ]] .) Окна моего терминала занимали около четырех секунд для открытия. Удалив файлы в /etc/paths.d и помещая их содержимое непосредственно в мой PATH в .bash_profile, окна терминала теперь загружаются мгновенно.

Обсуждение также включает ссылку на замену, написанную на Perl, github.com/mgprot/path_helper (нет представления о ее скорости, tho).

Изменить: из комментариев вышеупомянутого блога – патч к path_helper который должен стать другим способом устранения проблемы.

Я знаю, что следующее не влияет на скорость запуска нового терминала. Однако это укусило меня, поэтому я подумал, что поставлю свои два цента.

Я думаю, что на самом деле сомнительно, что этот вызов (для path_helper) находится в zshenv (который вызывается для всех оболочек, а не только для оконных оболочек). Для других оболочек вызов path_helper вместо этого находится в / etc / profile или в /etc/csh.login – которые вызывается только для оболочек входа.

Это становится проблемой, если вы запускаете утилиту «screen» под zsh. «screen» не запускает оболочку входа, но скорее наследует среду от вызывающей оболочки. Но он все равно вызовет / etc / zshenv и bu extension path_helper.

Так как это происходит, path_helper не только захватит кандидатов PATH из /etc/paths.d, но, если есть уже существовавший PATH, когда он вызван, он будет активно манипулировать этим PATH – он лишит компоненты, найденные в / etc / путей и /etc/paths.d и добавьте их. Таким образом, если вы положили $ {USER} / bin или / usr / local / bin во главе PATH (потому что вы хотите, чтобы ваши собственные программы были найдены первыми), то это не будет работать в сеансе «экрана».

Мое предложение исправить мою собственную проблему состоит в том, чтобы переименовать / etc / zshenv в / etc / zprofile (в настоящее время несуществующий), но я беспокоюсь, что это будет иметь негативные последствия … может быть, причина, по которой реализация zsh на OS X этот вызов в / etc / zshenv, и он наверняка будет сломан, когда выйдет следующая ОС, и я забуду все о своем исправлении.

Кто-нибудь еще видел это? Или есть мысли?