From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17309 invoked from network); 4 Aug 2003 06:00:31 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 4 Aug 2003 06:00:31 -0000 Received: (qmail 15254 invoked by alias); 4 Aug 2003 06:00:18 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6430 Received: (qmail 15245 invoked from network); 4 Aug 2003 06:00:17 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 4 Aug 2003 06:00:17 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [4.64.233.107] by sunsite.dk (MessageWall 1.0.8) with SMTP; 4 Aug 2003 6:0:16 -0000 Received: (from schaefer@localhost) by candle.brasslantern.com (8.11.6/8.11.6) id h7460FM15707 for zsh-users@sunsite.dk; Sun, 3 Aug 2003 23:00:15 -0700 From: Bart Schaefer Message-Id: <1030804060015.ZM15706@candle.brasslantern.com> Date: Mon, 4 Aug 2003 06:00:14 +0000 In-Reply-To: <20030803221858.GA2720@puritan.pcp.ath.cx> Comments: In reply to Nikolai Weibull "~/.zshenv or ~/.zprofile" (Aug 4, 12:18am) References: <20030803221858.GA2720@puritan.pcp.ath.cx> <20030803223949.GA18476@binome.blorf.net> In-Reply-To: <20030803223949.GA18476@binome.blorf.net> Comments: In reply to Wayne Davison "Re: ~/.zshenv or ~/.zprofile" (Aug 3, 3:39pm) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-users@sunsite.dk Subject: Re: ~/.zshenv or ~/.zprofile MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 ...