From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8993 invoked by alias); 17 Mar 2012 15:33:50 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16907 Received: (qmail 9425 invoked from network); 17 Mar 2012 15:33:48 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120317083331.ZM2339@torch.brasslantern.com> Date: Sat, 17 Mar 2012 08:33:31 -0700 In-reply-to: Comments: In reply to Mikael Magnusson "Re: root's path" (Mar 17, 12:21pm) References: <4F63ECD7.3040109@sergio.spb.ru> <87r4wr8opa.fsf@gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: root's path MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 17, 12:21pm, Mikael Magnusson wrote: } } > Shouldn't $PATH be set in /etc/zshenv rather than zprofile? } > Else, it's impossible to override $PATH in ~/.zshenv. } } Absolutely not, if you set PATH from *env, it makes it impossible to } inherit the PATH from the parent process' environment, even in } scripts, which will break a lot of things. I'd go further and say that except in carefully considered circumstances, the /etc/zshenv file should always be empty or not exist. If it does set the path, it should only append to it, not prepend or clobber (again, except in certain circumstances). } The path should only be set once on login of the current session, ie } in zprofile if zsh is your login shell, otherwise in the startup file } for your login shell. This is ideal but practically speaking has become unworkable in recent years. The use of remote terminals and window systems has resulted in an unpredictable variety of configurations such that there is no way to guarantee that any particular interactive shell is a login shell or was started from a login shell environment; i.e., "current session" is now pretty much meaningless in the process environment sense. In fact the OP's most likely problem is that on the "good system" he has a login shell (or there is one somewhere nearer the root of his process tree), but on the "bad system" he has only an interactive shell. So it's often necessary to adjust the path in /etc/zshrc to make sure it is sane for all interactive shells. Or, after careful consideration, to do so in /etc/zshenv if the path for NON-interactive shells is incomplete. -- Barton E. Schaefer