From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19610 invoked from network); 25 Mar 1999 20:04:45 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Mar 1999 20:04:45 -0000 Received: (qmail 3028 invoked by alias); 25 Mar 1999 19:43:23 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2240 Received: (qmail 3003 invoked from network); 25 Mar 1999 19:43:21 -0000 To: zsh-users@sunsite.auc.dk Sender: monnier@tequila.cs.yale.edu From: Stefan Monnier Newsgroups: lists.zsh.users Subject: Re: zsh startup files References: <5l1zidiw46.fsf@tequila.cs.yale.edu> <9903251400.AA54287@ibmth.df.unipi.it> Date: 25 Mar 1999 14:37:27 -0500 Message-ID: <5lyaklgy2w.fsf@tequila.cs.yale.edu> X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu NNTP-Posting-Host: tequila.cs.yale.edu X-Trace: 25 Mar 1999 14:37:27 -0500, tequila.cs.yale.edu >>>>> "Peter" == Peter Stephenson writes: > `No, this idea isn't popular', or `No, I am at war with the sysadmin who > doesn't make it easy'? I meant: no, the sysadmin(s) often just refuse changing something that (they claim) works. The mere fact that it makes user-configs clunky is nor considered important enough to take the risk of screwing up something in the config. Furthermore, they generally aren't even able to understand what the problem is and will give you answers like "well, with our default config I couldn't reproduce your problem". > Potentially, they may be useful, but I certainly agree they're overused and > often abused. On this system here, we have /etc/zprofile, /etc/zshenv and > /etc/zshrc --- and they're almost identical. Given my above description, I think software should always make it hard for the sysadmin to screw up and abuse a config. Currently, zsh tends to encourage such abuse (for instance /etc/zshrc should always be replaced by a `source /etc/user/zshrc' in the /etc/skel/.zshrc file so that the user is given the choice to turn it off or call it at some other time). >> I guess I could live with just NO_GLOBAL_RCS that I would >> set in my .zshenv although it won't do me any good as a sysadmin. > (Do you mean GLOBAL_RCS_FIRST, or are you proposing a different option for > not running global scripts apart from /etc/zshenv at all?) If it worked in. I'm proposing a new option. > .zshenv, it would certainly be made to work in /etc/zshenv: the question > would be whether it should have an effect in .zshenv as well. I think that any such flag should just take effect immediately, no matter when it is set. `setopt norcs' if executed in .zshrc should prevent /etc/zlogin and .zlogin from being executed. > Again, if you mean, `how do I get all my code to run after the global > scripts have finished', then I can't see any problem with the following, > but I haven't tried it out, so I may have missed something. I've relied on > the fact that .zshrc is run for any interactive shell (option interactive > is set), and .zprofile and .zlogin for any login shell (option login set), > and that a login shell is always interactive. That should answer your > other question. I was thinking of using something more like % cat .zshenv ... ...blabla... ... setopt norcs [[ -o login ]] && source .zprofile [[ -o interactive ]] && source .zshrc [[ -o login ]] && source .zlogin % Sadly, it seems that `setopt norcs' only takes effect in /etc/zshenv. Why was that deemed desirable ? How can I prevent /etc/zshrc from being sourced for interactive shells. Stefan