In zsh RPM /etc/zprofile has the following lines: # source profile if [ -f /etc/profile ]; then source /etc/profile fi /etc/profile in turns sources all .sh files under /etc/profile.d. If such a file contains an sh compatible if-evaluation, zsh initialization fails because zsh is not in sh-compatible mode: if [ "$VAR" == "VAL" ] then FOO=bar fi The error printed is: /etc/profile.d/test.sh:5: = not found This probably should be fixed in /etc/zprofile by using this: load-sh-profile() { emulate -L sh . /etc/profile } load-sh-profile Reference to a thread in zsh-users: http://www.zsh.org/mla/users/2007/msg00047.html
(The problem for zsh is "==", it is expecting "=".)
Also /etc/zshrc has something similar.
Oh, crap.. /etc/zshrc MUST NOT source /etc/profile or /etc/profile.d/*.sh - if so, they will override user settings in ~/.zprofile! Please consult zsh mailing lists if in doubt but the current behaviour is simply wrong. FWIW, my suggestion to fix this is that change /etc/zprofile as shown in comment 1 and remove these lines from /etc/zshrc: # from bashrc if [ "x$SHLVL" != "x1" ]; then # We're not a login shell for i in /etc/profile.d/*.sh; do if [ -r "$i" ]; then . $i fi done unset i fi
Ignore comment 3 as I opened a new bug for that case, see Bug 226344. Thanks.
Can we keep all this zsh incompatibility stuff in this bug, please? If you need reopen, change something or anything you cannot do (I have no idea why you were not able to reopen it, because reporter should be always able to reopen her own bug), just make a comment here, and I will fix it. All these bugs are really confusing to me, and I am not sure what the problems are now. Could you, please, upgrade your zsh to the last version (it is zsh-4.2.6-1 here) and restate what in your opinion is wrong with our default configuration? Thank you very much.
Ok, sorry for the noise. I'll list the two issues below. (I was not reporter of those other reports so I could not change their status, but for this bug I can.) Anyway, with zsh-4.2.6-1 there are two issues with zsh init scripts: 1) /etc/profile is sourced from /etc/zprofile, this is correct. For some reason sourcing of /etc/profile.d/*.sh was also added to /etc/zshrc, which is wrong since those get sourced always via /etc/profile. This prevents user to override any settings inherited from /etc/profile in her ~/.zprofile. Files /etc/zshrc and ~/.zshrc are for aliases, functions, completion control, etc, not for general environment variables, those should be in /etc/zprofile and ~/.zprofile in most cases. zshall man page has details about the order how these init scripts are processed. So to fix this, just remove the duplicate lines from /etc/zshrc (starting with "from bashrc" comment. I can't see any problems doing this. 2) The other is related to sourcing the file /etc/profile which should be a sh compatible scripts, as well as scripts under /etc/profile.d. zsh is not set into sh compatible mode before sourcing /etc/profile so some scripts that are sourced correctly with bash fail with zsh. An example of such a case was in comment 1. The fix was mentioned also above, in /etc/zprofile, replace current sourcing with: load-sh-profile () { emulate -L sh . /etc/profile } load-sh-profile This sets zsh into sh compatible mode, sources /etc/profile, and restores shell related options afterwards since this is done within a function. More about "emulate" and its options can be found from zshall man page. Thanks a lot.
Any progress with this one? Or do you need some more details? I'll happily provide any additional information. Bug 126539 is related but I think comment 6 summarizes the current situation with zsh init scripts pretty well. Thanks.
*** Bug 126539 has been marked as a duplicate of this bug. ***
This problem still exists in new zsh-4.3.4 package. Please consider fixing. Comment 6 best describes what is the problem.
This bug is now about two things, is messy in content, and partly a duplicate of Bug 430665 which is now closed (although its resolution is not agreed by everyone). I'll close this one as a duplicate of Bug 430665 and open a new one after Fedora 9 is out and the dust has settled. Thanks. *** This bug has been marked as a duplicate of 430665 ***