Bugzilla Bug 207037

In a login shell, user settings done in ~/.zshenv get overwritten by
/etc/zsh/zprofile when it calls /etc/profile.env.
This is because ~/.zshenv gets sourced before the zprofile and profile.env sets
absolute values and thus discarding the other ones...

In a non-login shell this does not happen as zprofile is ignored there.

So why don't you set these variables in your .zprofile?

What change do you expect?

.zprofile is only sourced by login shells. To be honest: for my problem it
would be an acceptable solution - but perhaps there are other cases which would
cannot be fixed this way... (e.g. if the terminal starts a non-login shell)

So currently to guarantee, that the correct env-vars are set, you either have
to put a "source .zshenv" in .zprofile (or vice versa) (which could result in
other problems though) - or duplicate all relevant values.

(In reply to comment #0)
> In a login shell, user settings done in ~/.zshenv get overwritten by
> /etc/zsh/zprofile when it calls /etc/profile.env.

(In reply to comment #2)
> .zprofile is only sourced by login shells.
> [...]
> but perhaps there are other cases which would
> cannot be fixed this way... (e.g. if the terminal starts a non-login shell)

/etc/zsh/zprofile is only sourced by login shells too. So we are talking about
login shells here.

> So currently to guarantee, that the correct env-vars are set, you either have
> to put a "source .zshenv" in .zprofile (or vice versa) (which could result in
> other problems though) - or duplicate all relevant values.

Honestly I still don't see the problem.

An example: you want to append something to $PATH - and you want all shells
(whatever their type is) to reflect this change.

With the current behavior you have to do two things:

To get the change in non-login shells: Modify .zshenv
To get the change in login shells: Modify .zshprofile

With other words: You have to do the change twice (which can result in a
maintaining nightmare).

Following the original zsh idea, you would only have to modify .zshenv.

(by the way: same problem exists for everything in /etc/zsh/zshenv)

So, I just spend some time reading old bug reports. This bug is in fact a
duplicate of bug #19924.

A possible solution is in StartupFiles/zshenv. What do you think about this?

(In reply to comment #5)
> So, I just spend some time reading old bug reports. This bug is in fact a
> duplicate of bug #19924.
> 
> A possible solution is in StartupFiles/zshenv. What do you think about this?
> 

Ok - sounds reasonable. :) So perhaps set this bug as a duplicate.

Thanks for your help and digging in old and moldy bugs :).

I am closing it as dup now. Anyway thanks for this report as i had to read some
old bugreports.

*** This bug has been marked as a duplicate of bug 19924 ***