idea of zsh feature

idea of zsh feature

[Rene Rideau]

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@ens.fr -- 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/"

Re: idea of zsh feature

[Zefram]

Rene Rideau wrote:
>* 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!

zsh can't really do anything about this.  It's the kernel that doesn't
distinguish between these two error conditions.  zsh could, I suppose, try
to stat(2) the executable if execve(2) returns ENOENT, but it's a kludge.

>* 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.

It's been discussed, but there are some major issues to be overcome.

>* Ideally, could it be possible to have a zsh-server,
> with all configuration read that would just fork on a new console?

The new `clone' module can do this.  With a couple of enhancements, it
could be very useful for purposes like this.

-zefram

Re: idea of zsh feature

[Peter Stephenson]

Zefram wrote:
> Rene Rideau wrote:
> >* Ideally, could it be possible to have a zsh-server,
> > with all configuration read that would just fork on a new console?
> 
> The new `clone' module can do this.  With a couple of enhancements, it
> could be very useful for purposes like this.

I was thinking about this and got as far as writing an xtermclone script.
The big problem seems to be xterm needs to fork its own process while
the zsh process needs to be forked from the old one.  This means you need
another sentinel process for the xterm which is a bit ugly.  Also, with
zsh as it stands it's hard to get that sentinel process to pause cleanly;
if that's going to be a common problem it would be worth adding a (trivial)
pause builtin to the module.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: idea of zsh feature

[Francois-Rene Rideau]

>>* make a difference between an executable program not being present
>> and its interpreter not being present:
>
> zsh can't really do anything about this.  It's the kernel that doesn't
> distinguish between these two error conditions.  zsh could, I suppose, try
> to stat(2) the executable if execve(2) returns ENOENT, but it's a kludge.
>
Yeah, that's precisely what I was thinking of.
Sure it's a kludge, but better a working kludge
than a non-working non-kludgy code?
This could be made a compile-time option, if you don't like it.
If you want, I could even write that code on my spare time.
Only I'm not familiar with zsh coding standards...

Other ideas:
* having built-in help modules
* Also, the user-level *path/*PATH feature,
 and/or perl-like split&join builtins
* having "functions", "declare", etc builtins properly quote characters,
 so that the output can be read back.
* Perhaps having a quote builtin on the purpose to quote all meta-characters
* having a way to make zsh very light-weight to run on linuxes with < 4Mb RAM

If I have more ideas, I'll e-mail you...

(Note: still not subscribed to any of the lists)

== Fare' -- rideau@ens.fr -- 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/"

Re: idea of zsh feature

[Zefram]

Peter Stephenson wrote:
>I was thinking about this and got as far as writing an xtermclone script.
>The big problem seems to be xterm needs to fork its own process while
>the zsh process needs to be forked from the old one.  This means you need
>another sentinel process for the xterm which is a bit ugly.

Right.  We really need a program that will close all its file descriptors
and block until the cloned zsh terminates.  The only real problem I
see is letting the process know the new zsh's PID -- although it can't
wait(2), it can poll in a pretty lightweight manner.  This applies to
any terminal, of course, not just xterm.

>                                                             Also, with
>zsh as it stands it's hard to get that sentinel process to pause cleanly;
>if that's going to be a common problem it would be worth adding a (trivial)
>pause builtin to the module.

I've been considering that myself.  A pause builtin would be generally
useful anyway, and I think it would more naturally fit into a module
offering sleep(1) as a builtin.  (We could, of course, enhance the sleep
builtin to use usleep(2), nanosleep(2) or select(2) for high-resolution
pauses.)

-zefram