Sourcing .zshrc from .zprofile causes problems

Sourcing .zshrc from .zprofile causes problems

[lists]

Hi list,
	When I put

if [[ -f ~/.zshrc ]]; then . ~/.zshrc ; fi

in my .zprofile, I get

.zshrc:unalias:181: no such hash table element: run-help

when launching a new Terminal window (this is under Mac OS 10.3.5 using 
zsh 4.2.0).  Lines 181-183 of my .zshrc file are as follows:

unalias run-help
autoload run-help
HELPDIR=~/.zsh_help

run-help is properly unaliased though.  The error message goes away 
when in don't source .zshrc in my .zprofile.  However, at that point 
the following zstyle from my .zshrc file

zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}

doesn't work when I open a new Terminal window (I don't see colors when 
I tab).  If I do 'exec zsh' in the new window, the zstyle does work.

Any ideas?  I'll happily post more from the dotfiles if that would help.

Thanks

Re: Sourcing .zshrc from .zprofile causes problems

[Bart Schaefer]

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 ?

Re: Sourcing .zshrc from .zprofile causes problems

[Philippe Troin]

Bart Schaefer <schaefer@brasslantern.com> writes:

> 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.

CDE, for one, and some old versions of gnome use a non-interactive
login shell starting the X session.

Phil.

Resolved: Sourcing .zshrc from .zprofile causes problems

[lists]

I figured it out.  It was because I had

zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}

before

export  
LS_COLORS='di=36:fi=0:ln=35:pi=93:so=32:bd=34;46:cd=34;103:or=31:mi=0: 
ex=31'

in my .zshrc file.  Silly me.  I know this is a bit off topic, but is  
the 'export' necessary/correct in the LS_COLORS definition?

Thanks,
Ryan


On Aug 13, 2004, at 12:11 AM, Bart Schaefer wrote:

> 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 ?

Re: Resolved: Sourcing .zshrc from .zprofile causes problems

[Vincent Lefevre]

On 2004-08-14 10:31:08 -0500, lists wrote:
> I figured it out.  It was because I had
> 
> zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
> 
> before
> 
> export  
> LS_COLORS='di=36:fi=0:ln=35:pi=93:so=32:bd=34;46:cd=34;103:or=31:mi=0: 
> ex=31'
> 
> in my .zshrc file.

You should define LC_COLORS in your .zshenv file.

> Silly me. I know this is a bit off topic, but is the 'export'
> necessary/correct in the LS_COLORS definition?

Yes, as it is needed by ls.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Resolved: Sourcing .zshrc from .zprofile causes problems

[Wayne Davison]

On Sat, Aug 14, 2004 at 08:20:36PM +0200, Vincent Lefevre wrote:
> You should define LC_COLORS in your .zshenv file.

Not necessarily.  The .zshenv file is for things that are needed by all
shells, including non-interactive scripts.  As such, I would suggest
just exporting LC_COLORS from .zprofile and leaving it alone.

The only thing I have in my .zshenv script is this:

if [[ $SHLVL == 1 && ! -o LOGIN ]]; then
    source ~/.zprofile
fi

This is a kludge that ensured that an xterm that didn't start with any
of my login settings sourced my .zprofile.  I'm not sure if it's still
needed with a modern X Windows setup, though.  Hmm, I wonder if that
works right with a cron-initiated zsh script?  Perhaps not...

I used to set things like the PATH in the .zshenv file until it caused
me problems using gdb:  gdb runs the executable using $SHELL, and that
caused some of my debug environment settings to get overridden (ouch).

..wayne..

Re: Resolved: Sourcing .zshrc from .zprofile causes problems

[Vincent Lefevre]

On 2004-08-14 21:58:45 -0700, Wayne Davison wrote:
> On Sat, Aug 14, 2004 at 08:20:36PM +0200, Vincent Lefevre wrote:
> > You should define LS_COLORS in your .zshenv file.
> 
> Not necessarily.  The .zshenv file is for things that are needed by all
> shells, including non-interactive scripts.

I know, but this may be useful if you do something like

  ssh host ls

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Resolved: Sourcing .zshrc from .zprofile causes problems

[Bart Schaefer]

On Sat, 14 Aug 2004, Wayne Davison wrote:

> The only thing I have in my .zshenv script is this:
> 
> if [[ $SHLVL == 1 && ! -o LOGIN ]]; then
>     source ~/.zprofile
> fi
> 
> I used to set things like the PATH in the .zshenv file until it caused
> me problems using gdb:  gdb runs the executable using $SHELL, and that
> caused some of my debug environment settings to get overridden (ouch).

I still set PATH in $ZDOTDIR/.zshenv (which I source from ~/.zshenv in
case ZDOTDIR isn't yet set) but I adopted this convention:

	if [[ -z $ZSH_ENVPATH ]]
	then
	  # ... various adjustments to $path including typeset -U) ...
	  export ZSH_ENVPATH=$PATH
	fi

This has the advantage of letting me check later whether something else 
has changed the path, and even force it back to its original state with 
PATH=$ZSH_ENVPATH.