Re: A peep into the future.

Re: A peep into the future.

[Bruce Stephens]

Vincent Lefevre writes:

> >     if you say "foo > Important_file", zsh checks to see if there
> >     is anything on the stdout of foo, if not (say foo is
> >     non-existent), zsh leaves the Imp_file as it is.
>
> Not a good idea. Sometimes I use this to clear a (temporary) file.
> You can set NO_CLOBBER. But sometimes it is not sufficient, e.g.
> one use >| then one types a wrong file name. So I'd prefer to have
> an automatical backup, e.g. "Important_file" is renamed to
> "Important_file.bak".

What, just add ".bak"?  It's a good idea, in principle, and I'm
surprised it's not been done.  But if it's to be done, then it ought to
follow the same conventions as some (but not all, alas) of the GNU
utilities, I think, in particular the file utilities.  Two or three
environment variables define the behaviour, which allows you to use
either simple backups or numbered backups, and if you use numbered
backups you can select how many to keep.
--
Bruce Stephens                  | email: B.Stephens@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Re: A peep into the future.

[Zefram]

>1. Fully programmable aliasing (matching regexps, replacing selections).

Not really likely for 3.0.  Maybe in 4.0 there could be an execcmd
function that gets called before each command is executed.

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

>3. Programmable key bindings (a key could be bound to a sequence of
>   actions, so now you can do things like: dynamic paren matching,
>   real-time indentation, etc.)  Some primitive functions have been
>   provided  (a small (but complete) subset of the EDITING functions 
>   of elisp).

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.

>4. Safer redirections: e.g.
>	if you say "foo > Important_file", zsh checks to see if there
>	is anything on the stdout of foo, if not (say foo is
>	non-existent), zsh leaves the Imp_file as it is.

That's probably better done using >>(command) redirection.  It could be
done as a global alias.

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

>6. Hierarchical option settings.  E.g. unsetopt zle automatically
>   unsetopts's the options dependant on its being set.  It itself also
>   is an option.  It's there to make understanding the plethora of
>   options easier for new users.

That's rather pointless.  If an option has no effect due to the state
of another option, I'd rather it stayed the way it is, rather than get
unset.

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

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

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

>4.  zsh now supports dynamic files.  If a file has a specific magic no,
>    it can be handled like a normal file of the *output* of that file.

Another virtual filesystem?

>zsh 10.0:
>
>OS_TYPE is a shell variables which can be changed.  zsh simulates the
>given OS.  Everything is a shell builtin.

I have a vision of being able to assign to $ZSH_VERSION, to make zsh
emulate an arbitrary version of itself.  It would be rather silly.

-zefram

Re: A peep into the future.

[Zoltan Hidvegi]

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

Re: A peep into the future.

[Mark Devlin]

On Tue, 4 Jun 1996, Harmanjit Singh wrote:

> Hello everybody,
> 
> Here's the dream:
> 
> Features in zsh 3.0:

> zsh 4.0:

> zsh 10.0:
> 
> OS_TYPE is a shell variables which can be changed.  zsh simulates the
> given OS.  Everything is a shell builtin.

To paraphrase Rob Reiner's mother:  I'll have what he's having.  :-)
 
- Mark
markd@eskimo.com	(finger markd@eskimo.com for my PGP signature)
http://www.eskimo.com/~markd	U.S.A. Home of the Alternate Reality page

Re: A peep into the future.

[Vincent Lefevre]

> 	if you say "foo > Important_file", zsh checks to see if there
> 	is anything on the stdout of foo, if not (say foo is
> 	non-existent), zsh leaves the Imp_file as it is.

Not a good idea. Sometimes I use this to clear a (temporary) file.
You can set NO_CLOBBER. But sometimes it is not sufficient, e.g.
one use >| then one types a wrong file name. So I'd prefer to have
an automatical backup, e.g. "Important_file" is renamed to
"Important_file.bak".

> 2.  mount/umount is a shell builtin which simulates working with
>     virtual filesystems e.g. ftpfs, tarfs, libfs, memfs.

(and zipfs)

This would be great! I'm used to RiscOS (on Acorn) with its "image
filing systems". Here it would be limited to the shell, but still
very useful.

Same kind of ideas:

I'd like also something like name directories but with paths, e.g.
instead of having only one directory associated with a name, one
has a list of directories (like with =command).

The '=' meaning could be command-dependent (like completions). The
default behavior could be the current one, and other meanings can
be defined, so that for instance one can type:

elm -f =folder

where elm_path=(~/Mail1 ~/Mail2) or something like that...

-- 
Vincent Lefevre, vlefevre@ens-lyon.fr | Acorn RiscPC600, 20+1MB RAM, Eagle M2
http://www.ens-lyon.fr/~vlefevre      | Apple CD-300, SyQuest 270MB
Magistere d'informatique, 3e annee    | Atari Falcon030, 4MB RAM
------------------------------------------------------------------------------