Where PATH is set

Where PATH is set

[Chris Johnson]

I have a political question I could use some help on.  My system
administrators currently set PATH in /etc/zshrc.  The assignment is
literal; no existing value is checked for.  They assign the exact same
thing to PATH in /etc/zshenv so that "ssh machine command" will work the
same way.

This setup forces me to similarly assign PATH twice, once in ~/.zshenv
and once in ~/.zshrc.  My changes to PATH in ~/.zshenv are overwritten
by the system's /etc/zshrc.  But I want PATH to contain the same
directories whether the shell is interactive or not.  So, I need to
assign to PATH again in ~/.zshrc.  I think this is a horrible setup, a
trap for inconsistencies just waiting to snare users, but the sysadmins
think its a non-issue.

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.  I've
pointed this out to my sysadmins, but they are looking for further
documentation and recommendation of this practice.  Does anyone have any
input that I could send their way?

I suppose you could disagree with me if you wanted to, but I won't
forward that along to them.

-- 
Chris Johnson
cjohnson@cs.utk.edu
http://www.cs.utk.edu/~cjohnson

Re: Where PATH is set

[William Scott]

Hi Chris:

If you want, you can have my system administrator:

% print $ZSH_VERSION
3.0.8

When I compiled 4.2.5, ours hid the compiler.

/etc/zshenv makes the most sense, but they should also be appending or
prepending directories as you point out.

The only real solution to such 'political' problems is to buy your own
computer and be your own system administrator. Unfortunately, this did
not result in a factor of 3 pay increase.

If you want the job done right, you have to do it yourself I am afraid,
unless, unlike me, you work at a real university, instead of DIYU.

Bill






On Tue, 5 Sep 2006, Chris Johnson wrote:

> I have a political question I could use some help on.  My system
> administrators currently set PATH in /etc/zshrc.  The assignment is
> literal; no existing value is checked for.  They assign the exact same
> thing to PATH in /etc/zshenv so that "ssh machine command" will work the
> same way.
>
> This setup forces me to similarly assign PATH twice, once in ~/.zshenv
> and once in ~/.zshrc.  My changes to PATH in ~/.zshenv are overwritten
> by the system's /etc/zshrc.  But I want PATH to contain the same
> directories whether the shell is interactive or not.  So, I need to
> assign to PATH again in ~/.zshrc.  I think this is a horrible setup, a
> trap for inconsistencies just waiting to snare users, but the sysadmins
> think its a non-issue.
>
> 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.  I've
> pointed this out to my sysadmins, but they are looking for further
> documentation and recommendation of this practice.  Does anyone have any
> input that I could send their way?
>
> I suppose you could disagree with me if you wanted to, but I won't
> forward that along to them.
>
> -- 
> Chris Johnson
> cjohnson@cs.utk.edu
> http://www.cs.utk.edu/~cjohnson
>

Re: Where PATH is set

[Bart Schaefer]

On Sep 5,  2:31pm, Chris Johnson wrote:
}
} I have a political question I could use some help on.  My system
} administrators currently set PATH in /etc/zshrc.

This is at least preferable to RedHat's idea of what belongs in that
file, which *still* includes "bindkey ' ' magic-space" and loading of
some files from /etc/profile.d/ that install aliases.  My personal
opinion is that the only thing that belongs in /etc/zshrc is setting
the default shell prompt, and I'm a bit leery even of that.

In any case it's redundant to set something in /etc/zshenv and then
set it again in any other /etc/z* file.  NOTHING stops /etc/zshenv
from being read; many things can bypass the rest of the files.

} The assignment is literal; no existing value is checked for. They
} assign the exact same thing to PATH in /etc/zshenv so that "ssh
} machine command" will work the same way.

Assigning PATH in /etc/zshenv is a perfectly reasonable thing to do,
particularly if important commands may reside in unexpected locations
like /opt/bin/ or even /usr/local/bin/.  Most exported variables are
reasonable candidates for /etc/zshenv, but practially nothing else is,
except maybe resource limits.

} This setup forces me to similarly assign PATH twice, once in ~/.zshenv
} and once in ~/.zshrc.

You could always put "setopt NO_GLOBAL_RCS" in ~/.zshenv and cause all
the rest of the /etc files to be skipped.  I used to do that, but those
/etc/profile.d/ files that annoy me so are unfortunately shared with
/etc/profile for bash, and therefore are are necessary to set up the
environment properly (e.g., for X11).

So, now, I do fun things like

    builtin alias alias='[[ $0 = /etc/* ]] || \alias'

which renders the alias command a no-op when it appears in any file
under /etc/.  If your sysadmins are doing

    export PATH=....

then you could play the same trick with the export command; but more
likely they have the assignment and the export as separate steps.

} I think this is a horrible setup, a trap for inconsistencies just
} waiting to snare users, but the sysadmins think its a non-issue.

Sysadmins have a different set of priorities.  They want to keep the
clueless from complaining, because it's much easier to deal with the
clueful -- even though you whine more, there aren't as many of you.

Put your PATH assignment (really, I hope it's a path assignment, the
array syntax is so much cleaner) in a third file, and "source" that
file from both ~/.zshenv and ~/.zshrc.

Re: Where PATH is set

[Wayne Davison]

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