Zsh Mailing List Archive
Messages sorted by:
- X-seq: zsh-users 1063
- From: Andrew Main <zefram@xxxxxxxxx>
- To: quinn@xxxxxxxxxxxxxxxxxxxxx (Quinn Dunkan)
- Subject: Re: stuff
- Date: Thu, 9 Oct 1997 10:13:51 +0100 (BST)
- Cc: zsh-users@xxxxxxxxxxxxxxx
- In-reply-to: <199710082313.QAA03342@xxxxxxxxxxxxxxxx> from "Quinn Dunkan" at Oct 8, 97 04:12:59 pm
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"
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
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.
Messages sorted by: