Re: stuff

[Andrew Main <zefram@xxxxxxxxx>]

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