From: Andrew Main <zefram@tao.co.uk>
To: quinn@envy.ugcs.caltech.edu (Quinn Dunkan)
Cc: zsh-users@math.gatech.edu
Subject: Re: stuff
Date: Thu, 9 Oct 1997 10:13:51 +0100 (BST) [thread overview]
Message-ID: <199710090913.KAA19628@taos.demon.co.uk> (raw)
In-Reply-To: <199710082313.QAA03342@tammananny.tiger> 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"
>*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
next prev parent reply other threads:[~1997-10-09 9:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-10-08 23:12 stuff Quinn Dunkan
1997-10-09 9:13 ` Andrew Main [this message]
1997-10-09 10:04 ` stuff Bruce Stephens
1997-10-09 18:22 ` stuff Tim Writer
1997-10-10 8:46 ` stuff Andrew Main
1997-10-10 17:12 ` stuff Tim Writer
1997-10-10 17:27 ` stuff Andrew Main
1997-10-14 21:17 ` stuff Tim Writer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199710090913.KAA19628@taos.demon.co.uk \
--to=zefram@tao.co.uk \
--cc=quinn@envy.ugcs.caltech.edu \
--cc=zsh-users@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).