Re: A peep into the future.

[Zoltan Hidvegi <hzoli@xxxxxxxxxx>]

> >2. Regular Expression filename generation.
> 
> We're pretty close to that, though not using the usual regexp syntax.
> It would be nice to add an option to use ksh's glob characters instead
> of zsh's.

That would be quite easy I think.  Just a few parsecomp* functions should
be modified and probably the lexer, tokenize() and maybe a few other
functions.  But ksh can also convert extended regular expressions to ksh
patterns uning the printf builtin.

> It's been discussed a bit.  I have some ideas of what would be
> required, but I don't expect anything to happen in this direction
> before 3.0.

Yes, definitely not before 3.0.

> >5. setopt POSIX_COMPLIANT now makes zsh what?
> 
> We should have an "emulate posix" mode, that turns on all POSIX
> features.  We have a long way to go before zsh is fully POSIX
> conformant.

I now managed to get the relevant POSIX document.  I'll read it and see
what are the necessary changes for POSIX compilance.  This does not mean
that zsh will be POSIX compilant but I'd like to know the places where we
should change zsh for that (of course POSIX behaviour would only be enabled
if zsh is invoked as sh or ksh).

> >zsh 4.0:
> >
> >1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
> >    and menu capabilities on text only terminals.  
> 
> It has colour capabilities to some extent: you can put colour sequences
> into prompts quite easily.  I don't see any advantage in having zsh use
> windows in any way.
> 
> >2.  mount/umount is a shell builtin which simulates working with
> >    virtual filesystems e.g. ftpfs, tarfs, libfs, memfs.

This is partially possible even now by defining shell functions for some
well-known commands.  Sometimes external commands can be used.  E.g. if I
write less b:patch.gz less will read patch.gz from the floppy using mtools,
uncompress the file with zcat and show it.  Or if I write less
zle_tricky.c.beta17 less will use co to show the contents of zle_tricky.c
in the beta17 release.  And I use less zle_tricky.c.rlog to see the
ChangeLog of zle_tricky.c (these tricks can be done using less 2.90 with a
sutable $LESSOPEN script (which is written in zsh of course).

> I'd like to see quite a lot of basic administration commands added as
> optional builtins, to make a sysadmin's shell.  There would be a
> configuration option to strip out ZLE, and to add builtins for cp, mv,
> rm, link, sln and so on.  That sort of shell would be very useful if
> statically linked and stashed away in /sbin.  Virtual filesystems, of
> course, should be done in the kernel (for example, userfs under
> Linux).

I have already did some private hacks to add loadable module support to
zsh.  This is quite trivial on elf systems (I did this on Linux) but I do
not know how can it be ported to non-elf systems.  But this is again will
not happen before 3.0.  With loadable modules everything can be done, one
can write as many builtins as she wish, and it would be possible to write a
module which can be used as an X interface.

> >3.  zsh can now byte-code its scripts.
> 
> I never tried this, but I think it used to be possible, if you just put
> the token control characters into a script.  Now zsh handles those
> properly, metafying them.  But an option to bypass metafication and
> tokenisation would potentially be fairly usable and easy to implement.

This would not improve the performance very much.  I tried gprof on zsh and
it turned out that less than 10 percent of the time was spent in the
lexer.  This percentage significantly decreases when there are loops in the
script since the body of a loop is parsed only once.  Shell functions are
also parsed only when you define them.

Zoltan