~/.zshenv or ~/.zprofile

~/.zshenv or ~/.zprofile

[Nikolai Weibull]

I've always put all my environment stuff in ~/.zshenv.  Lately, however,
I've come to realize that that may not be such a good idea.  I mean, the
environment is passed down as it is, why tell shells the same
information again?  The problem really is that if you put, for example,
your PATH definition in ~/.zshenv, and have a script or application that
modifies PATH and later runs a shell, that shell will not use the
specifically crafted PATH, but will read the standard one from
~/.zshenv.  An example would be procmail with ~/.procmailrc.  I have the
lines:
	PATH="/usr/bin:/bin"
	SHELL="/bin/zsh"
in my ~/.procmailrc.  I recently realized that, as I had set the shell
for procmail to invoke sub-processes with to Zsh, that the PATH setting
had no effect.  This was rather bad, as I was doing some echo debugging
in my ~/.zshenv and a lot of mails got messed up in the process.  So,
anyway, is there _any_ reason to put stuff in ~/.zshenv, and, if so,
what?
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star       :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,php,war3  :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: ~/.zshenv or ~/.zprofile

[Wayne Davison]

On Mon, Aug 04, 2003 at 12:18:58AM +0200, Nikolai Weibull wrote:
> The problem really is that if you put, for example, your PATH
> definition in ~/.zshenv, and have a script or application that
> modifies PATH and later runs a shell, that shell will not use the
> specifically crafted PATH, but will read the standard one from
> ~/.zshenv.

Exactly.  I got bit by this a few years ago when I had a .zshenv file
and was using gdb -- it runs a $SHELL to start the debugged program,
and this overrode some environment values that I did NOT want touched
(ouch).  I now use no .zshenv file at all, and I cannot think of any
good reason for me (or for most typical users) to need one.

I now use .zprofile and .zshrc, and I even have a special line in my
.zshrc file that sources .zprofile if it discovers that .zprofile has
not been sourced yet (which had happened to me in some circumstances
before, but is not a problem in my current situation where I first
login, and then run X Windows).

..wayne..

Re: ~/.zshenv or ~/.zprofile

[Bart Schaefer]

On Aug 4, 12:18am, Nikolai Weibull wrote:
}
} [...] environment is passed down as it is, why tell shells the same
} information again?

It depends how your shells commonly get invoked.  Most of my shells are
"xterm -e ssh some.other.host" and hence never have a custom environment.
On a few of those hosts zsh is not installed as a login shell and instead
gets launched from my startup files for whatever shell _is_ available.

Rather than go slowly insane trying to maintain separate startup files
on every such host, I've got a CVS tree of a standard set of files that
Almost Always Do The Right Thing, which of necessity includes a .zshenv.

} [...] An example would be procmail with ~/.procmailrc.  I have the
} lines:
} 	PATH="/usr/bin:/bin"
} 	SHELL="/bin/zsh"
} in my ~/.procmailrc.  I recently realized that, as I had set the shell
} for procmail to invoke sub-processes with to Zsh, that the PATH setting
} had no effect.

Unfortunately zsh is a rather bad choice for a shell to run from procmail
anyway.  Until quite recently zsh had a bug in reporting the exit status
of certain commands run via the -c option, which could cause procmail to
misfire on some rule conditions; and procmail makes assumptions about the
shell's behavior that zsh may violate when not emulating sh.

} So, anyway, is there _any_ reason to put stuff in ~/.zshenv, and, if
} so, what?

Here's what I have in my .zshenv:

- An "if" test to "unsetopt zle" when zsh is called by a certain silly
  program that deliberately invokes an interactive shell with no tty;

- Settings for the VERSION, ZSH_NAME, ZSH_VERSION, MACHTYPE, HOSTTYPE,
  and OSTYPE variables so that zsh versions from 3.0.x through 4.1.x
  have equivalent environments (I test these later, in other files);

- An alias for the alias command itself, so that idiotic /etc/z* files
  on e.g. RedHat Linux don't screw up the mv, cp, and mkdir commands;

- Settings of manpath, fpath, cdpath, and path -- but only if .zshenv
  has not already been sourced in this session, as determined by the
  value of another variable exported here (plus some other tests in
  the case of fpath, which is pointed into the zsh distribution tree
  when I run the binary from a build tree);

- A "source" command that reads a file of local tweaks for hosts where
  my standard set of files isn't quite sufficient;

- A big "cond" statement on HOSTTYPE that sets up functions or aliases
  so that a few commands like "df" or "rsh" have consistent semantics
  across operating systems (there's nothing so confusing as expecting
  remote shell but getting restricted shell, except maybe the inverse).

The aliases and functions are actually the most important bit, because
I want them set even for non-interactive shells and they are not part
of the environment.

A lot of this dates from the days when I was running zsh on around 20
different unix variants in a compile+QA farm, and amounts to dead code
... but every so often it comes in handy as a reference.

On Aug 3,  3:39pm, Wayne Davison wrote:
} 
} I now use no .zshenv file at all, and I cannot think of any good
} reason for me (or for most typical users) to need one.

Heh.  OK, I'm not going to bother arguing that I'm a typical user ...

Re: ~/.zshenv or ~/.zprofile

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

I'd like to change the StartupFiles/zshenv file so that it doesn't
recommend setting the "path".  How about something like the attached
patch?

..wayne..

[-- Attachment #2: zshenv.patch --]
[-- Type: text/plain, Size: 1484 bytes --]

--- StartupFiles/zshenv	25 Mar 2001 23:41:02 -0000	1.2
+++ StartupFiles/zshenv	7 Sep 2003 17:54:42 -0000
@@ -1,20 +1,18 @@
 #
-# Generic .zshenv file for zsh 2.7
+# Generic .zshenv file for zsh
 #
-# .zshenv is sourced on all invocations of the
-# shell, unless the -f option is set.  It should
-# contain commands to set the command search path,
-# plus other important environment variables.
-# .zshenv should not contain commands that product
-# output or assume the shell is attached to a tty.
+# .zshenv is sourced on ALL invocations of the shell, unless the -f option is
+# set.  It should NOT contain commands to set the command search path, or other
+# important environment variables unless you really know what you're doing.
+# E.g. running "PATH=/custom/path gdb program" sources this file (when gdb runs
+# the program via $SHELL), so you don't want to override a custom environment
+# in such cases.  Note also that .zshenv should not contain commands that
+# product output or assume the shell is attached to a tty.
 #
 
 # THIS FILE IS NOT INTENDED TO BE USED AS /etc/zshenv, NOR WITHOUT EDITING
 return 0	# Remove this line after editing this file as appropriate
 
-export X11HOME=/usr/X11
-
-path=($X11HOME/bin)
-path=($path /usr/ucb /usr/bin /usr/etc)
-path=($path /usr/local/bin)
-path=($path ~ .)
+# This kludge makes sure that certain /etc/z* files can't set aliases for rm,
+# mv, etc.  Just be sure to put "unalias alias" in your own rc file(s).
+alias alias=:

Re: ~/.zshenv or ~/.zprofile

[DervishD]

    Hi Wayne :)

 * Wayne Davison <wayned@users.sourceforge.net> dixit:
> I'd like to change the StartupFiles/zshenv file so that it doesn't
> recommend setting the "path".  How about something like the
> attached patch?

    The patch and the explanations seems to be quite useful. Anyway:
what is the proper place to set up the "path"? I mean globally not
per-user (that is, not ~/.*).

    Thanks in advance.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: ~/.zshenv or ~/.zprofile

[Dan Nelson]

In the last episode (Sep 07), DervishD said:
>  * Wayne Davison <wayned@users.sourceforge.net> dixit:
> > I'd like to change the StartupFiles/zshenv file so that it doesn't
> > recommend setting the "path".  How about something like the
> > attached patch?
> 
> The patch and the explanations seems to be quite useful. Anyway: what
> is the proper place to set up the "path"? I mean globally not
> per-user (that is, not ~/.*).

My global path settings are in zshenv, because that's the only one read
from scripts when your original login shell wasn't zsh and from cron
jobs.

path=(/usr/local/bin /usr/local/sbin /usr/bin /usr/sbin /usr/opt/*/bin /usr/opt/*/sbin $path)
typeset -U PATH

The typeset removes duplicate entries.

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: ~/.zshenv or ~/.zprofile

[DervishD]

    Hi Dan :)

 * Dan Nelson <dnelson@allantgroup.com> dixit:
> In the last episode (Sep 07), DervishD said:
> >  * Wayne Davison <wayned@users.sourceforge.net> dixit:
> > > I'd like to change the StartupFiles/zshenv file so that it doesn't
> > > recommend setting the "path".  How about something like the
> > > attached patch?
> > The patch and the explanations seems to be quite useful. Anyway: what
> > is the proper place to set up the "path"? I mean globally not
> > per-user (that is, not ~/.*).
> My global path settings are in zshenv, because that's the only one read
> from scripts when your original login shell wasn't zsh and from cron
> jobs.

    Well, that was my doubt ;))
 
> path=(/usr/local/bin
> typeset -U PATH

    Good solution! Just one more question: if the user runs, as in
the example, 'PATH=whatever gdb program', this is because the user
wants JUST that path, no more, no less. Shouldn't be a better
approach something like:

    [[ -z "$path" ]] && path=(mypath $path)
    typeset -U path

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: ~/.zshenv or ~/.zprofile

[Dan Nelson]

In the last episode (Sep 08), DervishD said:
>  * Dan Nelson <dnelson@allantgroup.com> dixit:
> > My global path settings are in zshenv, because that's the only one
> > read from scripts when your original login shell wasn't zsh and
> > from cron jobs.
> 
> Well, that was my doubt ;))
>  
> > path=(/usr/local/bin
> > typeset -U PATH
> 
> Good solution! Just one more question: if the user runs, as in the
> example, 'PATH=whatever gdb program', this is because the user wants
> JUST that path, no more, no less. Shouldn't be a better approach
> something like:
> 
>     [[ -z "$path" ]] && path=(mypath $path)
>     typeset -U path

That won't work because cron and /usr/bin/login give you a minimal
PATH.  You could have it test another variable like "NODEFAULTPATH" or
something.

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: ~/.zshenv or ~/.zprofile

[DervishD]

    Hi Dan :)

 * Dan Nelson <dnelson@allantgroup.com> dixit:
> >     [[ -z "$path" ]] && path=(mypath $path)
> >     typeset -U path
> That won't work because cron and /usr/bin/login give you a minimal
> PATH.  You could have it test another variable like "NODEFAULTPATH" or
> something.

    In fact, that won't work because the OK will give you a minimal
PATH (at least under Linux), and even /sbin/init will provide a more
sophisticated one. The best solution is to test for SHLVL or, just as
you say, set NODEFAULTPATH or another variable acting as a marker.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: ~/.zshenv or ~/.zprofile

[Phil Pennock]

On 2003-09-07 at 22:27 -0500, Dan Nelson wrote:
> My global path settings are in zshenv, because that's the only one read
> from scripts when your original login shell wasn't zsh and from cron
> jobs.

Similarly, I want to be able to do:
% ssh some-host command-in-company-bin-dir -oPts |less
and not have to worry about paths.

So I use zshenv, since it's the only pair of files sourced to set
variables.

If I'm going to worry about things like gdb, then I'll wrap the $path
setting inside a $SHLVL test -- if $SHLVL is set and is greater than or
equal to 2, then, and only then, assume that $PATH has been set
appropriately on this host.

Would fail when invoking zsh from a bash shell, were it not that I tend
to "exec zsh", which doesn't increase $SHLVL.
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: ~/.zshenv or ~/.zprofile

[DervishD]

    Hi Phil :)

 * Phil Pennock <phil.pennock@globnix.org> dixit:
> On 2003-09-07 at 22:27 -0500, Dan Nelson wrote:
> > My global path settings are in zshenv, because that's the only one read
> > from scripts when your original login shell wasn't zsh and from cron
> > jobs.
> If I'm going to worry about things like gdb, then I'll wrap the $path
> setting inside a $SHLVL test -- if $SHLVL is set and is greater than or
> equal to 2, then, and only then, assume that $PATH has been set
> appropriately on this host.

    Much better than my crap solution, that doesn't work since PATH
is set by the OS before exec'ing '/sbin/init' O:))

    Your solution is far better ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: ~/.zshenv or ~/.zprofile

[Wayne Davison]

On Mon, Sep 08, 2003 at 09:47:29AM +0000, Phil Pennock wrote:
> Similarly, I want to be able to do:
> % ssh some-host command-in-company-bin-dir -oPts |less
> and not have to worry about paths.

Another solution for that is to use ~/.ssh/environment (as long as the
"PermitUserEnvironment yes" option is set in the sshd_config file).  It
also has the benefit of working regardless of what login shell you might
have on a particular machine.

In any case, I consider this "knowing what you're doing", since it is
necessary to protect the setting of such variables via something like
the checking of $SHLVL.

..wayne..

Re: ~/.zshenv or ~/.zprofile

[Phil Pennock]

On 2003-09-08 at 10:55 -0700, Wayne Davison wrote:
> Another solution for that is to use ~/.ssh/environment (as long as the
> "PermitUserEnvironment yes" option is set in the sshd_config file).  It
> also has the benefit of working regardless of what login shell you might
> have on a particular machine.

Heh -- on various Solaris boxes here, my .zshenv (or system zshenv)
builds $PATH at run-time, by setting $path to uniqueness and adding
various globs using zsh glob modifiers.

typeset -aU path
typeset -x PATH
path=(
	/foo
	/opt/special-priority/bin
	/bar
	/usr/*/bin(/)
	/opt/*/bin(/)
     )

I could mess around with cronjobs to keep that more up-to-date.  I could
do so and create a file in bourne-compatible syntax, sourced from
/etc/profile.  I could do many things.

I keep things simple and set $path in zshenv -- it's understandable and
doesn't lead to other people having to wade through docs which I've
written or reverse-engineer stuff themselves.

If set in /etc/zshenv then this stuff can contain some highly
system-dependent locations.

zsh rocks.
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: ~/.zshenv or ~/.zprofile

[Wayne Davison]

On Sun, Sep 07, 2003 at 11:24:33PM +0200, DervishD wrote:
> what is the proper place to set up the "path"? I mean globally not
> per-user (that is, not ~/.*).

I believe that the /etc/zprofile script should do this so that it
happens once per login.

..wayne..

Re: ~/.zshenv or ~/.zprofile

[Wayne Davison]

On Sun, Sep 07, 2003 at 10:57:10AM -0700, Wayne Davison wrote:
> I'd like to change the StartupFiles/zshenv file so that it doesn't
> recommend setting the "path".

I've checked in an improved version of my zshenv file.  In addition to
some minor language improvments and the correction of an age-old
spelling error, I added a section that attempts to give advice to those
that want to use .zshenv to set their PATH.  Namely:

# Some people insist on setting their PATH here to affect things like ssh.
# Those that do should probably use $SHLVL to ensure that this only happens
# the first time the shell is started (to avoid overriding a customized
# environment).  Also, the various profile/rc/login files all get sourced
# *after* this file, so they will override this value.  One solution is to
# put your path-setting code into a file named .zpath, and source it from
# both here (if we're not a login shell) and from the .zprofile file (which
# is only sourced if we are a login shell).
if [[ $SHLVL == 1 && ! -o LOGIN ]]; then
    source ~/.zpath
fi

Seems like a pretty good solution to me -- do you agree?

Finally, I'd like to know how to get the zsh.org web sites to update
with the new zshenv?  Does this happen automatically?

..wayne..

Re: ~/.zshenv or ~/.zprofile

[Oliver Kiddle]

Wayne Davison wrote:

> Seems like a pretty good solution to me -- do you agree?

Looks good to me. And certainly better than before.

> Finally, I'd like to know how to get the zsh.org web sites to update
> with the new zshenv?  Does this happen automatically?

Do you mean the one at http://zsh.sunsite.dk/Contrib/startup/std/zshenv

It has to be updated manually which I have now done. Propagation of the
change to zsh.sf.net and b2pi.com should be automatic though (they run
rsync in a cron job).

Oliver

Re: ~/.zshenv or ~/.zprofile

[Dan Nelson]

In the last episode (Aug 04), Nikolai Weibull said:
> I've always put all my environment stuff in ~/.zshenv.  Lately,
> however, I've come to realize that that may not be such a good idea. 
> I mean, the environment is passed down as it is, why tell shells the
> same information again?  The problem really is that if you put, for
> example, your PATH definition in ~/.zshenv, and have a script or
> application that modifies PATH and later runs a shell, that shell
> will not use the specifically crafted PATH, but will read the
> standard one from ~/.zshenv.  An example would be procmail with
> ~/.procmailrc.  I have the lines:
> 	PATH="/usr/bin:/bin"
> 	SHELL="/bin/zsh"
> in my ~/.procmailrc.  I recently realized that, as I had set the
> shell for procmail to invoke sub-processes with to Zsh, that the PATH
> setting had no effect.  This was rather bad, as I was doing some echo
> debugging in my ~/.zshenv and a lot of mails got messed up in the
> process.  So, anyway, is there _any_ reason to put stuff in
> ~/.zshenv, and, if so, what?

zshenv is the only script sourced by cron jobs, so I put PATH and shell
functions I might use in scripts in there.  BTW - do this so you don't
override an existing PATH:

path=(/usr/local/bin /usr/local/sbin /sbin /usr/sbin /bin /usr/bin $path)
typeset -U PATH # remove duplicate entries

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: ~/.zshenv or ~/.zprofile

[Nikolai Weibull]

* Dan Nelson <dnelson@allantgroup.com> [Aug, 04 2003 12:40]:
>
> zshenv is the only script sourced by cron jobs, so I put PATH and shell
> functions I might use in scripts in there.  BTW - do this so you don't
> override an existing PATH:
>
> path=(/usr/local/bin /usr/local/sbin /sbin /usr/sbin /bin /usr/bin $path)
> typeset -U PATH # remove duplicate entries
>
yes, but that's not the issue here.  i wan't a restricted path, that's
why i modify $PATH.
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star       :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,php,war3  :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: ~/.zshenv or ~/.zprofile

[Zefram]

Nikolai Weibull wrote:
>                    The problem really is that if you put, for example,
>your PATH definition in ~/.zshenv, and have a script or application that
>modifies PATH and later runs a shell, that shell will not use the
>specifically crafted PATH, but will read the standard one from
>~/.zshenv.

When I run an interactive zsh, I want my customised environment
from ~/.zshenv regardless of what the parent process was doing.
$SHELL shouldn't be being used for any other purpose; a program that
wants a shell to interpret a command it's just generated should be using
/bin/sh directly, or, if it wants zsh, should be using /usr/bin/zsh -f.

Unfortunately there are many programs that are not well-behaved, and
use $SHELL as a non-interactive command interpreter, expecting it to
interpret some particular shell command language.  With make and procmail
(both of which are badly-behaved in this manner), it is wise to always
explicitly set SHELL=/bin/sh in the configuration file.

-zefram