From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14465 invoked from network); 13 Aug 2004 05:14:50 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 13 Aug 2004 05:14:50 -0000 Received: (qmail 61989 invoked from network); 13 Aug 2004 05:14:44 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Aug 2004 05:14:44 -0000 Received: (qmail 22167 invoked by alias); 13 Aug 2004 05:14:00 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7822 Received: (qmail 22156 invoked from network); 13 Aug 2004 05:14:00 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by 130.225.247.90 with SMTP; 13 Aug 2004 05:14:00 -0000 Received: (qmail 60639 invoked from network); 13 Aug 2004 05:12:01 -0000 Received: from unknown (HELO moonbase.zanshin.com) (167.160.213.139) by a.mx.sunsite.dk with SMTP; 13 Aug 2004 05:11:58 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i7D5Btk9008339 for ; Thu, 12 Aug 2004 22:11:55 -0700 Date: Thu, 12 Aug 2004 22:11:55 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-users@sunsite.dk To: zsh-users@sunsite.dk Subject: Re: Sourcing .zshrc from .zprofile causes problems In-Reply-To: <7E0A2482-ECC4-11D8-A541-000A95D2C79E@kalama.no-ip.org> Message-ID: References: <7E0A2482-ECC4-11D8-A541-000A95D2C79E@kalama.no-ip.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=-0.9 required=6.0 tests=BAYES_10 autolearn=no version=2.63 X-Spam-Hits: -0.9 On Thu, 12 Aug 2004, lists wrote: > if [[ -f ~/.zshrc ]]; then . ~/.zshrc ; fi > > in my .zprofile That shouldn't be necessary. The ~/.zshrc is read by all interactive shells, and the ~/.zprofile by all login shells. Although it's possible to create a non-interactive login shell, it's rather unlikely. So the problem here ... > .zshrc:unalias:181: no such hash table element: run-help ... is that the ~/.zshrc is read _twice_, once when you source it and then again when zsh normally would read it, and the second time run-help has already been unaliased. > The error message goes away when in don't source .zshrc in my .zprofile. Yep. > However, at that point the following zstyle from my .zshrc file > > zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS} > > doesn't work There must be some kind of order-dependency involved. The normal sequence of file reads (where you fail to see colored listings) would be (ignoring zshenv and zlogin for now) /etc/zprofile ~/.zprofile /etc/zshrc ~/.zshrc To make colored listings work, you've changed the order to /etc/zprofile ~/.zprofile + ~/.zshrc /etc/zshrc ~/.zshrc When you "exec zsh" chances are it's no longer a login shell, so the two zprofile files are not sourced in that case ... since coloring works then, that would tend to indicate that something in the ~/.zprofile is causing the problem, and it would have to be something that comes after the point where you inserted the sourcing of ~/.zshrc. Does ~/.zprofile perhaps change the value of $LS_COLORS ?