Re: stuff

[Tim Writer <Tim.Writer@xxxxxxxxxx>]

Andrew Main <zefram@xxxxxxxxx> 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@xxxxxxxxxx
FTL Solutions Inc.
Toronto, Ontario, CANADA