From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 369 invoked from network); 9 Oct 1997 09:38:49 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Oct 1997 09:38:49 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id FAA21070; Thu, 9 Oct 1997 05:13:55 -0400 (EDT) Resent-Date: Thu, 9 Oct 1997 05:13:26 -0400 (EDT) From: Andrew Main Message-Id: <199710090913.KAA19628@taos.demon.co.uk> Subject: Re: stuff To: quinn@envy.ugcs.caltech.edu (Quinn Dunkan) Date: Thu, 9 Oct 1997 10:13:51 +0100 (BST) Cc: zsh-users@math.gatech.edu In-Reply-To: <199710082313.QAA03342@tammananny.tiger> from "Quinn Dunkan" at Oct 8, 97 04:12:59 pm X-Loop: zefram@tao.co.uk X-Headers: in preparation X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_W3LG3.0.285.r0AFq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1063 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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. >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. >FITNR = ? Fixed In The Next Release. 3.1.3 in this case. >I thought I'd throw this idea out and see what people think... zsh could have >a status line on the bottom of the screen, which would give info such as time, >loadavg, mail, anything the user wanted, really ("click here to start" >*shudder*). That sort of thing can go in the prompt. If your terminal has an actual status line, it can use that. >haven't played around with the module interface yet---can you override internal >zsh functions, or just add new builtins? Somewhere between. You can override anything that the base code explicitly allows to be overridden. >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.) > For those who prefer rc / es syntax over 'normal' shells, I >don't suppose it would be possible for a module to override zsh's syntax parser >(or better yet, just make the the default parser be sh-ksh-csh.so, then when >you do ``emulate ksh'' or something, it dumps sh-ksh-csh.so and loads ksh.so)? Potentially possible. I'd like to play with this idea. > Hell, you could >link a syntax module in with libperl and come up with that perl shell >everyone's always asking about. That's actually going one step beyond another idea I'd had -- to link libperl into a module that provides the perl command as a builtin. -zefram