Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Where PATH is set
- X-seq: zsh-users 10688
- From: Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>
- To: Chris Johnson <cjohnson@xxxxxxxxxx>
- Subject: Re: Where PATH is set
- Date: Tue, 5 Sep 2006 23:16:57 -0700
- Cc: zsh-users@xxxxxxxxxx
- In-reply-to: <20060905183120.GA10848@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20060905183120.GA10848@xxxxxxxxxxxxxxxxxx>
On Tue, Sep 05, 2006 at 02:31:20PM -0400, Chris Johnson wrote:
> Peter has some lines in the zsh Guide, section 2.5.10, about how zshenv
> is the cleanest place to set environment variables, PATH included.
It's my belief that you need to be careful to not force values in an
*env file that you might want to override. For instance, if you ever
want to pass a custom PATH to a program, you can get bitten by this:
PATH=/custom/bin program # works fine
PATH=/custom/bin gdb program
(gdb) r # might NOT work
The above discrepancy is because gdb uses $SHELL to spawn "program".
So, if one of the *env rc files sets PATH unconditionally, you can never
start a sub-shell with a custom PATH (or whatever other environment
variable gets set unconditionally).
I like to set environment variables in .zprofile, and then I also put
some kluge code in .zshenv that ensures that the file didn't get
skipped (which can happen if your login method didn't execute a login
shell, as is the case with some--but not all--X11 setups):
if [[ $SHLVL == 1 && ! -o LOGIN ]]; then
source ~/.zprofile
fi
..wayne..
Messages sorted by:
Reverse Date,
Date,
Thread,
Author