Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 225454 - zsh should be set sh compatible when sourcing sh scripts
Summary: zsh should be set sh compatible when sourcing sh scripts
Status: CLOSED DUPLICATE of bug 430665
Alias: None
Product: Fedora
Classification: Fedora
Component: zsh
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: James Antill
QA Contact:
: 126539 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-30 18:08 UTC by Daniel Qarras
Modified: 2018-04-11 19:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-16 19:45:59 UTC

Attachments (Terms of Use)

Description Daniel Qarras 2007-01-30 18:08:02 UTC
In zsh RPM /etc/zprofile has the following lines:

# source profile
if [ -f /etc/profile ]; then
        source /etc/profile

/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" ]

The error printed is:

/etc/profile.d/ = not found

This probably should be fixed in /etc/zprofile by using this:

load-sh-profile() {
  emulate -L sh
  . /etc/profile


Reference to a thread in zsh-users:

Comment 1 Daniel Qarras 2007-01-30 18:09:54 UTC
(The problem for zsh is "==", it is expecting "=".)

Comment 2 Daniel Qarras 2007-01-30 20:46:39 UTC
Also /etc/zshrc has something similar.

Comment 3 Daniel Qarras 2007-01-30 21:10:53 UTC
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

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
    unset i

Comment 4 Daniel Qarras 2007-01-31 20:47:23 UTC
Ignore comment 3 as I opened a new bug for that case, see Bug 226344. Thanks.

Comment 5 Matěj Cepl 2007-01-31 22:13:07 UTC
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

Thank you very much.

Comment 6 Daniel Qarras 2007-01-31 23:15:11 UTC
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

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.

Comment 7 Daniel Qarras 2007-04-14 16:23:01 UTC
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.


Comment 8 Matěj Cepl 2007-04-16 15:24:42 UTC
*** Bug 126539 has been marked as a duplicate of this bug. ***

Comment 9 Daniel Qarras 2007-10-12 20:48:14 UTC
This problem still exists in new zsh-4.3.4 package. Please consider fixing.
Comment 6 best describes what is the problem.

Comment 10 Daniel Qarras 2008-04-16 19:45:59 UTC
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.


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

Note You need to log in before you can comment on or make changes to this bug.