From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id GAA02576 for ; Wed, 5 Jun 1996 06:49:49 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id QAA12995; Tue, 4 Jun 1996 16:38:27 -0400 (EDT) Resent-Date: Tue, 4 Jun 1996 16:37:33 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199606042037.WAA00359@bolyai.cs.elte.hu> Subject: Re: A peep into the future. To: A.Main@dcs.warwick.ac.uk (Zefram) Date: Tue, 4 Jun 1996 22:37:41 +0200 (MET DST) Cc: zsh-users@math.gatech.edu In-Reply-To: <1062.199606041027@stone.dcs.warwick.ac.uk> from Zefram at "Jun 4, 96 11:27:47 am" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GoAR11.0.XA3.Cw9jn"@euclid> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/232 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > >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