Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 19924 - app-shells/zsh - Please move /etc/zsh/zprofile to /etc/zsh/zshenv to fix environment.
Summary: app-shells/zsh - Please move /etc/zsh/zprofile to /etc/zsh/zshenv to fix envi...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Tim Harder
URL:
Whiteboard:
Keywords:
: 102189 148196 207037 348622 363133 (view as bug list)
Depends on:
Blocks: 159890
  Show dependency tree
 
Reported: 2003-04-25 07:00 UTC by James Michael Fultz
Modified: 2013-07-16 19:18 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
/etc/zsh/zprofile (zprofile,279 bytes, text/plain)
2003-04-25 07:05 UTC, James Michael Fultz
Details
zshenv (zshenv,443 bytes, text/plain)
2003-09-06 09:17 UTC, Mamoru KOMACHI (RETIRED)
Details
sample zprofile to preserve users' path (zprofile-preserve-path.diff,573 bytes, patch)
2004-04-16 10:09 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Michael Fultz 2003-04-25 07:00:13 UTC
I had previously submitted a file for use as `/etc/zsh/zshenv' which has gone
into use. While it is functional and was certainly an improvement over the
pre-existing setup, I no longer believe it was entirely the correct solution.
Having consulted the Zsh documentation regarding its start up files and compared
that with that of other shells, I think that `/etc/zsh/zprofile' is the proper
file to be used for what is now being done in `/etc/zsh/zshenv'. Therefore, I
think that `/etc/zsh/zshenv' should be removed and replaced by
`/etc/zsh/zprofile'. I will be creating an attachment for use as `/etc/zsh/zprofile'
Comment 1 James Michael Fultz 2003-04-25 07:05:29 UTC
Created attachment 11119 [details]
/etc/zsh/zprofile

This is very similar to my old `/etc/zsh/zshenv'. A notable tweak is removing
the unnecessary `/usr/bin/whoami' command substitution and replacing it with
the Zsh `USER' environment variable. This is, at least, a bit more efficient by
removing the execution of an external command.
Comment 2 Wayne Davison 2003-06-19 10:04:57 UTC
Yes, I agree.  The zshenv file got sourced in inappropriate times (i.e. at
every shell invocation).  For instance, if I ran less, it invoked zsh to run
lesspipe.sh, and zshenv gets sourced (which is not desired).

The only sticky problem is how to handle the old zshenv file when installing
the new zprofile file.  I submitted a potential solution in my zsh 4.1.1
ebuild that renames the user's zshenv file to zprofile (if they don't have
a zprofile file already) during the pkg_preinst step, and then our install
of the zprofile file will handle any user changes during the etc-update step.
See bug 23114 for my 4.1.1 ebuild.
Comment 3 Graham Forest 2003-06-28 01:11:54 UTC
So long, and thanks for all the fish
Comment 4 Mamoru KOMACHI (RETIRED) gentoo-dev 2003-07-23 10:54:18 UTC
Thank you for your contribution. Both of your comments helped
me a lot. /etc/zsh/zprofile is included in zsh-4.0.7.ebuild 
in CVS now.
Comment 5 Danek Duvall 2003-07-28 22:39:19 UTC
Hm.  I just found this bug, and I'm not sure that this is the right thing.
I agree that zshenv isn't the right file for this, but zprofile is sourced
only at the startup of a login shell.  Which means that other interactive,
but not login, shells won't source this file.  This is different from bash,
whose man page says that /etc/profile is sourced for all interactive shells
or noninteractive login shells, but the same as ksh, which says its sources
/etc/profile only on login.  So obviously there's room for interpretation.
Just something to think about.
Comment 6 James Michael Fultz 2003-07-29 01:08:01 UTC
My understanding of what Bash's man page states is that `/etc/profile' is read by Bash only when it is a login shell (interactive and non-interactive).

Quoting Bash's man page, fourth paragraph from the section "INVOCATION":

"When  bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes  commands  from  the file /etc/profile, if that file exists. ..."
Comment 7 Mamoru KOMACHI (RETIRED) gentoo-dev 2003-07-29 05:18:47 UTC
You can check the behaviour of interactive and login shell:

zsh:
rico% export PATH=/bin:/usr/bin
rico% (zsh -c printenv | grep '^PATH')
PATH=/bin:/usr/bin
rico% (zsh -i -c printenv | grep '^PATH')
PATH=/bin:/usr/bin
rico% (zsh -l -c printenv | grep '^PATH')
PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin
rico% (zsh -l -i -c printenv | grep '^PATH')
PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin

bash:
bash-2.05b$ export PATH=/bin:/usr/bin
bash-2.05b$ (bash -c printenv | grep '^PATH')
PATH=/bin:/usr/bin
bash-2.05b$ (bash -i -c printenv | grep '^PATH')
PATH=/bin:/usr/bin
bash-2.05b$ (bash -l -c printenv | grep '^PATH')
PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin
bash-2.05b$ (bash -l -i -c printenv | grep '^PATH')
PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin

From the manpage as James suggested, I think this is the right
behaviour and not a bug.
Comment 8 Seemant Kulleen (RETIRED) gentoo-dev 2003-09-06 04:07:25 UTC
reopen requested
Comment 9 ajs 2003-09-06 04:18:37 UTC
The problem with this solution is that it may stomp over a user's .zshenv file if that's where they modify their own private PATH. The same goes for anything in set by /etc/profile.env which the user tries to set.

AFAIK all environment settings should go in /etc/zsh/zshenv. This always gets sourced, sure, but it's possible to detect if you're a login and/or interactive shell and skip most of the parsing if that's the case.

The INTERACTIVE and LOGIN options are the appopriate things to test for, I hope.

If I get a chance later this weekend I'll try to come up with a suitable set of replacement /etc/zsh/* files.

Cheers,

 - Andrew
Comment 10 Mamoru KOMACHI (RETIRED) gentoo-dev 2003-09-06 09:17:37 UTC
Created attachment 17161 [details]
zshenv
Comment 11 Mamoru KOMACHI (RETIRED) gentoo-dev 2003-09-06 09:32:28 UTC
Hi.  I was asked about the same issue two or three weeks ago at local forum
but he didn't reopen this bug ....  I understand it is a bit annoying if you use
~/.zshenv to set PATH enviroment.  I attached a zshenv file to parse
/etc/profile.env if [[ ${SHLVL} = 1 ]].  It may be [[ -o LOGIN ]] (if
you prefer zsh options).  Which do you think is better?
Comment 12 ajs 2003-09-06 11:16:43 UTC
Personally, as a matter of style I think [[ -o LOGIN ]] is preferable since it's obvious what it's doing; the SHLVL==1 thing may be functionally equivalent but it's less clear what it's doing at a glance.

Thanks for the prompt response,

 - Andrew
Comment 13 Wayne Davison 2003-09-06 11:53:13 UTC
The problem here is that there is confusion about what .zshenv should be used for. The statment that all environment variables should go into a zshenv file (either personal or system) is incorrect. The *env files are simply sourced for all invocations of the shell, and should only be used to make modifications that need to affect every shell invocation. Many people think that they need to set their PATH in the .zshenv file, and then they get royally screwed if they do something like this:

    PATH=/testing/path:/usr/bin gdb test-program

This completely ignores the custom PATH if their .zshenv file sets the PATH (this is because gdb runs the program using $SHELL).

So, for most people, they need to move things out of their .zshenv file into their .zprofile file.  In certain older X Windows environments, the .zprofile file did not get sourced, but that can be checked for and sourced in the users .zshrc file (or they can upgrade their X Windows version).
Comment 14 ajs 2003-09-06 23:56:21 UTC
Wayne:

Your example seems fair enough, and I admit I'd never thought of that (or been royally screwed in the manner you suggest). I was also under the impression that all environment settings go in *env, possibly due to its name. Speaking to a few friends who use zsh, it appears to be a fairly common perception.

Reading the man page actually doesn't offer advice of what goes where; it only describes the behaviour. The FAQ question "3.2: In which startup file do I put...?" (<http://zsh.sunsite.dk/FAQ/zshfaq03.html#l18>) offers a bit more guidance, and indeed does advise that *login and *shrc are "are a good place to set environment variables (i.e. export commands), since they are passed on to all shells without you having to set them again".

So I guess the initial closure for this bug was indeed correct and I should fix my personal startup files. :)

 - Andrew
Comment 15 Khayyam 2003-09-10 10:25:43 UTC
quote=Wayne Davison:

"The problem here is that there is confusion about what .zshenv should be used
for .."

/etc/zsh/zshenv *is* the place for $path and .zshenv *should* be considerd the
place to change this env. Look at StartupFiles/zshenv and you will see that
this is what zshenv is intended for, and .zshenv should be respected as "the
place" for a user to change this. Go to zsh.org and look at the .zshenv under
startup files and you will see that $path is defined here .. it's standard and
accepted practice.

In my own case $path is pretty much all I define in .zshenv, and it's a fairly
sure bet I will want this defined for each and every invocation .. as of the
4.0.7 update I *can't* define it here as it gets redefined in /etc/zsh/zprofile.

" .. for most people, they need to move things out of their .zshenv file into
their .zprofile file"

No .. the package maintainer should follow the practices layed out by the
zsh developers and have $path in /etc/zsh/zshenv. Additionally /etc/profile.env
should not be sourced but env-update should be addapted to also support zsh.

"PATH=/testing/path:/usr/bin gdb test-program"

How may people do you think would really do this???!!

As for defining $path it can be done in a simple array:

# .zshenv   
                                                                                          
# PATH
typeset -U path
export path
                                                                                            
path=($path ~/bin /path/bin)
Comment 16 Wayne Davison 2003-09-10 11:34:44 UTC
"Look at StartupFiles/zshenv ..."

Yes, I'm about to commit a patch to zsh to fix this comment, so it won't be there to mislead people much longer (yes, I'm one of the developers working on zsh). I too used to have many of my environment variables set in the .zshenv file, and I very nearly corrupted a production system at work a few years ago because of this.

So, we need to be sure that environment customizations aren't lost at every shell invocation. The gdb example was just one such command that can bite people, and simply should have made it clear that improper use of the .zshenv file can bite you unexpectedly. There are lots more potential pitfalls (basically anything that uses $SHELL).

So, having the system set PATH once in /etc/zprofile is the right place for it to happen.  If you want to have your .zshenv file override a setting from /etc/zprofile, you can either link your .zshenv to your .zprofile file, as Bart suggests here:

http://www.zsh.org/mla/users/1997/msg00575.html

Or, source it from that file (if you have other things in your .zprofile).
Comment 17 Per Wigren 2004-03-13 01:57:36 UTC
Here is a ZSH $PROMPT which looks identical to the default Gentoo BASH-prompt, both for root and for users:

PROMPT=$'%{\e[1;3%(!.1.2)m%}%n@%m %{\e[34m%}%1d %(!.#.$) %{\e[0m%}'

Please include it in the default zprofile.

If you want it distinguishable (is that a word?:) from BASH here is the prompt I use personally. It's almost identical to the Gentoo BASH-default but it uses ~ for $HOME and % instead of $ for users.

PROMPT=$'%{\e[1;3%(!.1.2)m%}%n@%m %{\e[34m%}%1~ %# %{\e[0m%}'
Comment 18 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-03-13 02:32:07 UTC
I personally do not want to enable such a prompt by default.
I committed Gentoo prompt like yours yesterday, bug #43753,
but only added einfo to let users do the job by themselves.
I like the idea of distinguising zsh prompt from bash prompt,
so I'll change $ to % and home directory to ~ in the next
prerelease.

If there are a number of people who want to enable it by default,
I'll do so, but I'll add ``vanilla'' local IUSE flag for users
who don't want it. What do you think about it?
Comment 19 Lawrence Kesteloot 2004-04-03 21:10:04 UTC
If I add ~/bin to PATH in my .zshenv, then it's clobbered by /etc/zsh/zprofile.  If I move that to my .zshrc or .zprofile, then it doesn't get sourced when I ssh into the machine to run a program, like "ssh machine program".  In that case "program" isn't searched in ~/bin.  If I link .zprofile to .zshenv or source .zshenv from .zprofile, then .zshenv will get sourced twice for login shells (not the end of the world, but lame).

For those of you who were advocating moving PATH out of .zshenv, how do you handle the "ssh" problem?

(The "ssh" problem came up because subversion in ssh mode tries to run "svnserve" and it must be in your path.)

Perhaps a solution is to have /etc/zsh/zprofile save the PATH on invocation, source /etc/profile.env, then merge the two paths afterwards.
Comment 20 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-04-16 10:09:19 UTC
Created attachment 29430 [details, diff]
sample zprofile to preserve users' path

So probablly it's better to add a patch like this?

It only preserve users' PATH (scripts in /etc/env.d set many other
environment variables but you cannot stop them clearing your settings
in ~/.zshenv if we stick to use /etc/zsh/zprofile).
Comment 21 Lawrence Kesteloot 2004-12-19 18:58:04 UTC
Mamoru: Your patch works for me, but like you said it only saves PATH, not MANPATH, CLASSPATH, etc.  So I'm going to keep linking $HOME/.zprofile to $HOME/.zshenv for safety, even though it's slightly wasteful.  It really does seem like zsh's default behavior is wrong, and it should always source the system files first, letting the user override using local files.

I suppose another option is to have /etc/profile.env check each variable before setting it.  Path variables would be appended and non-path variables (e.g., LESS and CC) would be left alone if they were already set.  Yuk.
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2005-08-12 00:50:52 UTC
*** Bug 102189 has been marked as a duplicate of this bug. ***
Comment 23 Jakub Moc (RETIRED) gentoo-dev 2006-09-19 08:30:22 UTC
*** Bug 148196 has been marked as a duplicate of this bug. ***
Comment 24 Ryan 2006-09-21 14:44:51 UTC
This doens't really have that much in common with this bug, but apperently some dev thought it did, so I will repost what I said in the other thread.  The issue with with JAVA_HOME not being set accordingly with the new java-config.  The code was updated with bash profile, but not zsh, and probably other shells also, but these bug looks like it is dead, and being ignored, so nothing will porbably come of this.

Anyhow, this is what I found.


in /etc/profile, there this code

for sh in /etc/profile.d/*.sh ; do
   if [ -r "$sh" ] ; then
      . "$sh"
   fi
done
unset sh

/etc/zsh/zprofile does not have this.  Thereforce my java vm was being set by
the old way in env.d directory.  This was preventing me from using java 1.5.  I
check the zprofile in the zsh files dir, and this code is not in there.

I think it might need to be added, I read through the docs and didn't see
anything about messing with the shell's profile.T
Comment 25 Michele Noberasco (RETIRED) gentoo-dev 2007-01-16 08:20:29 UTC
sys-apps/qingy is affected by this bug, too. If zsh does not have the system PATHs set in /etc/zsh/zprofile, qingy is not able to fire up X sessions because xinit can't find the X server in PATH.
Comment 26 Mamoru KOMACHI (RETIRED) gentoo-dev 2007-04-30 16:27:39 UTC
Sorry for the delay. Changed zprofile to source /etc/profile.d/*.sh as suggested in comment #24.
Comment 27 Ryan 2007-04-30 17:07:08 UTC
no problem ... also note that you now have to extract the value of EDITOR in zprofile also.  Here is the code I use ... stolen from /etc/profile/

# Extract the value of EDITOR
[ -z "$EDITOR" ] && EDITOR="`. /etc/rc.conf 2>/dev/null; echo $EDITOR`"
[ -z "$EDITOR" ] && EDITOR="/bin/nano"
export EDITOR


As for the profile.d/*.sh, this is now how they do it, not sure if it really matters

for sh in /etc/profile.d/*.sh ; do
        [ -r "$sh" ] && . "$sh"
done
unset sh


Thanks for adding this , it will make new commers to zsh life a bit easier
Comment 28 Mamoru KOMACHI (RETIRED) gentoo-dev 2007-04-30 19:32:39 UTC
Sure, it is reported on bug #165000 and fixed in CVS.
Thanks anyway for the information, Ryan :-)
Comment 29 Brian S. Stephan 2007-05-07 06:07:36 UTC
(In reply to comment #26)
> Sorry for the delay. Changed zprofile to source /etc/profile.d/*.sh as
> suggested in comment #24.
> 

A note, this will cause a warning if the directory does not contain any .sh

/etc/zsh/zprofile:34: no matches found: /etc/profile.d/*.sh

I made an empty .sh (dummy.sh :) to make zsh not complain when logging in.
Comment 30 Torsten Veller (RETIRED) gentoo-dev 2008-03-17 10:21:24 UTC
*** Bug 207037 has been marked as a duplicate of this bug. ***
Comment 31 Torsten Veller (RETIRED) gentoo-dev 2011-01-18 08:51:09 UTC
*** Bug 348622 has been marked as a duplicate of this bug. ***
Comment 32 Torsten Veller (RETIRED) gentoo-dev 2011-04-11 16:57:53 UTC
*** Bug 363133 has been marked as a duplicate of this bug. ***
Comment 33 Michael Weber (RETIRED) gentoo-dev 2011-04-11 19:20:49 UTC
If you've found this bug, you might be interested in

mv /etc/zsh/zprofile /etc/zsh/zshenv

This works ith the current stable app-shells/zsh-4.3.11-r1
Comment 34 rking 2012-07-24 15:05:50 UTC
Why is this marked "RESOLVED FIXED"?

For anyone starting with a fresh Gentoo install, they will get a real puzzle if they're coming from a system without a $PATHological reset in between ~/.zshenv and ~/.zshrc

The sudo mv /etc/zsh/{zprofile,zshenv} fix works. Why is it not in the standard package?

Thanks!
Comment 35 Michael Weber (RETIRED) gentoo-dev 2012-07-27 06:48:42 UTC
(In reply to comment #34)
> Why is this marked "RESOLVED FIXED"?
Let's re-open and assign to current maintainers.

> ... $PATHological ...
nice.

> The sudo mv /etc/zsh/{zprofile,zshenv} fix works. Why is it not in the
> standard package?

@maintainers, can you fix this, please?

For now, I've an hook in /etc/portage/env/<category>/<package> [1]

x ~ # cat /etc/portage/env/app-shells/zsh 
pkg_preinst() {
        mv -v "${D}"/etc/zsh/{zprofile,zshenv} || die
}

[1] http://devmanual.gentoo.org/ebuild-writing/functions/pkg_preinst/index.html
Comment 36 rking 2012-08-02 03:23:57 UTC
Michael Weber:

Cool workaround. I didn't know about those hooks.  Thanks.

Now let's hope the maintainers are around to fix it for real.
Comment 37 rking 2012-08-21 19:17:21 UTC
No love from the maintainers?
Comment 38 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-06-09 12:54:35 UTC
Ping.
Comment 39 Tim Harder gentoo-dev 2013-06-25 19:01:11 UTC
Fixed in 5.0.2-r2.
Comment 40 Mike Gilbert gentoo-dev 2013-06-29 05:05:37 UTC
I'm re-opening this because having this installed as /etc/zsh/zshenv is clobbering my PATH setting from ~/.zprofile.

These environment variables should be set once, at login, not for every shell invocation.
Comment 41 Mike Gilbert gentoo-dev 2013-06-29 05:15:18 UTC
(In reply to Mike Gilbert from comment #40)

Scratch that; my old (modified) copy of /etc/zsh/zprofile was clobbering my settings after I moved PATH to .zshenv. That was quite confusing.

I would suggest adding a warning to pkg_postrm if /etc/zsh/zprofile exists, as may happen due to config-protection.
Comment 42 Mike Gilbert gentoo-dev 2013-06-29 05:16:01 UTC
pkg_postint I mean.
Comment 43 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2013-07-15 20:57:41 UTC
+1

Its been breaking my $PATH every time script with zsh shebang is running.
Comment 44 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2013-07-15 21:02:06 UTC
as /etc/zsh/zshenv is executed EVERY SINGLE time zsh is executed, it SHOULD NOT touch $PATH or any other variable. PATH variable should be set at zprofile, as thats what is done on login shell. All non-login shells does inherit variables from parent. This 'bugfix' acctualy broken my system.
Comment 45 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2013-07-15 21:09:24 UTC
Use case & proof of concept:

I have .zshrc that setup a log of variables, including PATH. When script is executed it does not run zshrc or zprofile, which is all right, but it does run zshenv, after you put PATH settings and /etc/profile.d/* into zshenv, it does replace all my variables with default one. Its so wrong and evil that I can't believe it was commited to tree. profile.d alone is meant to be executed on login, only login, not every single zsh spawn (script, another terminal in X/tmux/screen/whatever).
Comment 46 Tim Harder gentoo-dev 2013-07-15 23:41:05 UTC
(In reply to Piotr Karbowski from comment #45)
> Use case & proof of concept:
> 
> I have .zshrc that setup a log of variables, including PATH. When script is
> executed it does not run zshrc or zprofile, which is all right, but it does
> run zshenv, after you put PATH settings and /etc/profile.d/* into zshenv, it
> does replace all my variables with default one. Its so wrong and evil that I
> can't believe it was commited to tree. profile.d alone is meant to be
> executed on login, only login, not every single zsh spawn (script, another
> terminal in X/tmux/screen/whatever).

We can either use a variable as a flag in the system's zshenv and only source the file if the variable is unset or revert to using a system zprofile and tell users they should be using .zprofile instead of .zshenv to override PATH, etc. Personally I'm fine with a flag variable, any other ideas/opinions?

The following is an example of what could be prepended to the system zshenv:

# Only source this the first time the shell is started to avoid overriding
# customized environments.
if [ -n "$ZSHGENTOO" ] ; then
   return
fi
export ZSHGENTOO=1
Comment 47 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2013-07-16 14:18:06 UTC
Well, Whatsoever we should not provide zshenv, but zprofile. This whole bugreport, as a feature enhance is wrong, zprofile shoudn't be ever changed into zshenv, all export should be done in zprofile, zshenv have so minimal usecase (a file that is executed with every zsh instance, interactive and non-interactive, including scripts) that it shoudn't be imo ever shipped with ebuild.

Example of valid usecase for zshenv would be, for example, turning on ksh mode, global, so you could run ksh scripts with zsh shebang without any edition. Thats a borderline usecase, but still valid.

Keeping it short, in my very opinion:

1. ebuild should provide zprofile and never zshenv.
2. user's config should be in .zshrc, which is inserted into interactive shell.

adding the kind of export you proposed is really wrong, as it would emulate zprofile (run it only once, on login), but there is no reason to do so, you can just leave it as zprofile.

The feedback I got from zsh side clearly say that zshenv is WRONG place to set PATH.
Comment 48 Tim Harder gentoo-dev 2013-07-16 18:11:34 UTC
(In reply to Piotr Karbowski from comment #47)
> Well, Whatsoever we should not provide zshenv, but zprofile. This whole
> bugreport, as a feature enhance is wrong, zprofile shoudn't be ever changed
> into zshenv, all export should be done in zprofile, zshenv have so minimal
> usecase (a file that is executed with every zsh instance, interactive and
> non-interactive, including scripts) that it shoudn't be imo ever shipped
> with ebuild.
...

Right, this is upstream's standard documented method which I agree we should try to adhere to. Probably the best thing would be to revert to using a system zprofile and add an elog pointing to the zshenv example installed into docs that mentions setting path and/or output other information so people quit reopening this bug. :P
Comment 49 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2013-07-16 18:24:38 UTC
+1 for revert into old zprofile thingy. shipping examples in /usr/share is of course good idea, as it can be dropped into user home and is not destructive to have it there. ;-)
Comment 50 Tim Harder gentoo-dev 2013-07-16 19:18:23 UTC
(In reply to Tim Harder from comment #48)
> Probably the best thing would be to revert to using a
> system zprofile and add an elog pointing to the zshenv example installed
> into docs that mentions setting path and/or output other information so
> people quit reopening this bug. :P

This has been done in zsh-5.0.2-r3; however, the elog message is only shown for new installs. I'll paste the information here so people hopefully quit opening this bug when they try to set PATH in ~/.zshenv and find it gets overridden.

New info outputted by the ebuild:

Note that a system zprofile startup file is installed. This will override PATH and possibly other variables that a user may set in ~/.zshenv. Custom PATH settings and similar overridden variables can be moved to ~/.zprofile or other user startup files that are sourced after the system zprofile.

If PATH must be set in ~/.zshenv to affect things like non-login ssh shells, one method is to use a separate path-setting file that is conditionally sourced in ~/.zshenv and also sourced from ~/.zprofile. For more information, see the zshenv example in ${EROOT}/usr/share/doc/${PF}/StartupFiles/.