Re: ~/.zshenv or ~/.zprofile

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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