Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
idea of zsh feature
- X-seq: zsh-workers 2981
- From: Rene Rideau <rideau@xxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: idea of zsh feature
- Date: Tue, 11 Mar 1997 20:15:08 +0000 (WET)
- Reply-to: Fare Rideau <rideau@xxxxxxxxxxxxxx>
Dear zsh workers,
I hope I'm not disturbing you. I'm not subscribed to any zsh list,
but I've been a happy zsh user for years.
Here are a few ideas of features, in case you didn't consider them yet:
* make a difference between an executable program not being present
and its interpreter not being present:
if foo begins by #!/invalid/path
then zsh will complain:
zsh: no such file or directory: foo
Which means lots of time being spent figuring where the error was!
* would it be possible to dump part or all of the state of zsh
for fast loading? I have *long* configuration files for the great zsh.
autoload functions are not space efficient. [I've heard you already
began binary modules -- sorry]
* Ideally, could it be possible to have a zsh-server,
with all configuration read that would just fork on a new console?
Under Linux, I have to spawn a zsh on a new console.
on systems with a /dev/fd, there could even be called by a zsh-client
such that the forked server process would "steal" the fd's from the client,
that would wait until the forked process dies.
* Another solution might be to have a shared memory/mmapedfile
that would contain some "global" zsh data
* Of course, default behavior should be secure, and sharing should
happen only with an explicit flag.
Anyway, thanks for your wonderful work,
that turns Unix into an almost livable system!
== Fare' -- rideau@xxxxxx -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"
Messages sorted by:
Reverse Date,
Date,
Thread,
Author