From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25838 invoked by alias); 10 Feb 2011 17:53:09 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28732 Received: (qmail 15172 invoked from network); 10 Feb 2011 17:53:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110210095253.ZM30860@torch.brasslantern.com> Date: Thu, 10 Feb 2011 09:52:52 -0800 In-reply-to: Comments: In reply to Greg Klanderman "Re: loading user startup files for zsh scripts" (Feb 10, 11:30am) References: <19792.22365.139876.599478@gargle.gargle.HOWL> <110207213357.ZM22407@torch.brasslantern.com> <20110208172056.6a985c90@pwslap01u.europe.root.pri> <110208205856.ZM24066@torch.brasslantern.com> <110209085358.ZM29014@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: loading user startup files for zsh scripts MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 10, 11:30am, Greg Klanderman wrote: } } Unfortunately I cannot modify /etc/zshenv on the one to two hundred } people's machines that are using our shared zsh startup files at work; } I can suggest they modify ~/.zshenv but it's unlikely to be widely } followed, which is why I was looking for a solution in the shared file } sourced by ~/.zshenv, but it sounds like that just can't work. Hmm. Yeah, I tried examining things like $funcfiletrace etc. and they don't provide any additional information. I can suggest a draconian solution: make update more than a suggestion. Change your shared file to have it require that $0 be passed as an argument, e.g. source /the/shared/zshenv $0 This shows up as $1 in your shared file. Have the file do NOTHING if there is no $1, otherwise test $1 against $ZSH_NAME, etc. Maybe if the shell is interactive, print a warning. That way your users are forced to update their ~/.zshenv if they want to continue getting the benefit of your shared file. If you want to be even MORE draconian, give them a week and then have the file call exit if there is no $0, so their shells just plain die until they fix it. (Exclude login shells from that approach ...) --