From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4967 invoked from network); 9 Oct 1997 18:47:21 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Oct 1997 18:47:21 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id OAA03528; Thu, 9 Oct 1997 14:41:37 -0400 (EDT) Resent-Date: Thu, 9 Oct 1997 14:41:00 -0400 (EDT) X-Authentication-Warning: snoopy.ftlsol.com: tim set sender to Tim.Writer using -f Sender: tim@ftlsol.com To: Andrew Main Cc: quinn@envy.ugcs.caltech.edu (Quinn Dunkan), zsh-users@math.gatech.edu Subject: Re: stuff References: <199710090913.KAA19628@taos.demon.co.uk> From: Tim Writer Date: 09 Oct 1997 14:22:38 -0400 In-Reply-To: Andrew Main's message of Thu, 9 Oct 1997 10:13:51 +0100 (BST) Message-ID: X-Mailer: Gnus v5.4.37/XEmacs 19.15 Resent-Message-ID: <"OeVxA1.0.8q.yKIFq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1070 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Andrew Main writes: > Quinn Dunkan wrote: > >Uh, maybe you're talking about different zshenvs? That bit about ``put them > >in zshenv'', and ``You shouldn't have anything in /etc/zshenv'' confused me a > >bit. Likely the first zshenv was ~/.zshenv? > > Right. Normal setup should go in ~/.z*. /etc/z* should be basically > transparent, and used only for site-specific unavoidable hacks. > > > Currently I have in /etc/zshenv > >zmodload dependencies, setopts, and a bunch of vars (everything non-interactive > >shells could use). > > Those should go in ~/.zshenv, except possibly the zmodload bits. > By setting variables, and especially options, in /etc/zshenv, you are > changing the semantics of zsh. > > The system I use here, at work, illustrates this point quite well. > /etc/zshrc contains some bindkeys for escape sequences sent by local > terminals, which is quite valid. /etc/profile, however, is basically > taken from one of the Linux distributions, and sets up all sorts of > environment variables -- enabling colour ls, and providing a rather poor > LESSOPEN -- which make life awkward for me, so I have to override all > of these variables in my .profile. But isn't that just the point. Knowledgeable users like yourself can override global settings and get the environment they like. But less knowledgeable users don't have the skills, so system administrators, who may be responsible for managing a large number of machines and assisting a large number of users, really have no choice but to provide a reasonably nice (site specific) environment (i.e. not the default) via /etc/z*. Keeping novices and experts happy is hard. Ultimately, most sys. admins. are going to do whatever makes their job easier. > >If this wasn't a single user system I'd stick setopts in .zshenv, but I don't > >want cron jobs, sendmail prog agents, etc. running zsh scripts in unexpected > >ways, so they're global. > > Don't write scripts to run in your customised enviroment. Write them > for plain zsh -f. Good advice, but not always easy to follow. Sometimes scripts have to be aware of the customized environment because there purpose is to report on it or manipulate it. Again, I'm thinking of a sys. admin. writing support scripts for less knowledgeable users. > >Speaking of es, I wonder if zsh could steal some of es's features, such as > >settor functions. > > I've been considering doing that for a while. I can see a number of uses > for it, and we could actually remove the hardcoded special handling of > most special variables. (PATH and path, for example, could each have > a settor function that sets the other.) Doesn't ksh '93 have similar functionality? I think they're called discipline variables. Perhaps zsh should go that route as ksh emulation seems to be a clear goal. Speaking of ksh '93, what about hierarchical variables? -- Tim Writer Tim.Writer@ftlsol.com FTL Solutions Inc. Toronto, Ontario, CANADA