zsh-3.0.0 released

zsh-3.0.0 released

[Zoltan Hidvegi]

-----BEGIN PGP SIGNED MESSAGE-----

Finally, here is zsh-3.0.0!

This message just goes to zsh-workers.  An other announcement will be
posted to zsh-announce and to some newsgroups.

The -DDEBUG flag is removed from the default CFLAGS but developers are
still encouraged to use it.  Even better to use

./configure --enable-zsh-{mem,{mem-,}debug,secure-free}

but this will create a bit bigger and slower executable (note that it does
not work on all systems).

Tomorrow I'll leave for a one week holiday.  I'll be back next Friday
evening but do not be surprised if won't answer any mails before Saturday
or Sunday.

See the ChangeLog for the full list of the changes.

The new release can be found on the following anonymous ftp sites.  The
first is the official archive site.  The rest are mirror sites which are
kept frequently up to date.  The sites maked with a star may mirror
ftp.math.gatech.edu instead of the primary site.

   HUNGARY
      ftp://ftp.cs.elte.hu/pub/zsh/  -- primary site
      ftp://ftp.kfki.hu/pub/packages/zsh/

   Australia
    * ftp://ftp.ips.oz.au/pub/packages/zsh/

   Finland
      ftp://ftp.funet.fi/pub/unix/shells/zsh/

   France
      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/

   Germany
      ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh/
    * ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/

   Japan
      ftp://ftp.tohoku.ac.jp/mirror/zsh/
      ftp://shirakaba.nis.co.jp/pub/shells/zsh/

   Norway
    * ftp://ftp.uit.no/pub/unix/shells/zsh/

   Slovenia
      ftp://ftp.siol.net/pub/unix/shells/zsh/

   Sweden
      ftp://ftp.lysator.liu.se/pub/unix/zsh/

   UK
      ftp://ftp.net.lut.ac.uk/zsh/

   USA
      ftp://ftp.math.gatech.edu/pub/zsh/
      ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
    * ftp://ftp.sterling.com/zsh/
    * ftp://ftp.rge.com/pub/shells/zsh/

The primary archive site is also accessible via http from
   http://www.cs.elte.hu/pub/zsh/.

The files (times are in GMT-2):

    21803 Aug 15 19:44 zsh-3.0-pre6-final-3.0.0.diff.gz
   628435 Aug 15 19:43 zsh-3.0.0.tar.gz
  1327843 Aug 15 19:44 zsh-RCS.tar.gz
   730962 Aug 15 19:06 zsh-doc.tar.gz

The md5 checksums:

a1a60a05f0bd595aa06b18632a616ff3  zsh-3.0-pre6-final-3.0.0.diff.gz
b815af64c1298bcd738ab20240cac3a8  zsh-3.0.0.tar.gz
bfcbc58984072d29eae5793371623b50  zsh-RCS.tar.gz
e81fa69eeb1c15994958e866e3434dca  zsh-doc.tar.gz

If you already have zsh-3.0-pre6, you can apply the patch in
zsh-3.0-pre6-final-3.0.0.diff.gz and you do not need to download the full
source.  To do this just cd into the directory where the zsh-3.0-pre6
sources are kept and issue

gzip -dc zsh-3.0-pre6-final-3.0.0.diff.gz | patch -p
touch stamp-h.in configure

Zoltan

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBMhNoXAupSCiLN749AQFvKgP9G+H5e4U0k+7i+lw2y3sW1IfIa4vMK+8W
D8DASidomImkfKTP0eq6wDLPjguQPaKK2nbdIW966aoZF+Sp/NOQe+KAMkPDgzRK
C0uwcBVIEnJjfoT8Lxb04xJr1cLaOFfS04Gz1GR1JF2e408US4TehM3kub2aLHhI
daig219sJQQ=
=kCXU
-----END PGP SIGNATURE-----

Re: zsh-3.0.0 installed in the US

[Tom Kaczmarski]

Beautiful, last time I installed it I had to bastardize the code a little 
to make it work.  This time, NO PROBLEMS.

OS = Solaris 2.5

Tom

                                           ?
                                         ''~``
                                        ( o o )
+----------------------------------.oooO--(_)--Oooo.------------------------+

   mailto:tkaczma@luc.edu
                           http://orion.it.luc.edu/~tkaczma
                                     .oooO                  (312) 512-7302
                                     (   )   Oooo.
+-------------------------------------\ (----(   )--------------------------+
                                       \_)    ) / 
                                             (_/

Re: zsh-3.0.0 installed in the US

[Andrew Cosgriff]

** "tk" == Tom Kaczmarski <tkaczma@math.luc.edu> writes:

tk> Beautiful, last time I installed it I had to bastardize the code a little
tk> to make it work.  This time, NO PROBLEMS.

tk> OS = Solaris 2.5

That's odd.  Here, on Solaris 2.3, configure doesn't add an -lnsl to the
libraries to be linked in.  I reported this a few weeks back, but it seems to
still be happening.

Enjoy,
 Andrew.
-- 
 - Andrew J Cosgriff - ajc@bing.wattle.id.au -          Mobile : +61-14-856-122
 SysAdmin / Support Dude, UNICO Computer Systems    PGP & MIME ok and preferred
     The meaning of a word is what is explained by the explanation of the
    meaning.        -- Ludwig Wittgenstein, "Philosophical Investigations"

Re: zsh-3.0.0 installed in the US

[Tom Kaczmarski]

On 16 Aug 1996, Andrew Cosgriff wrote:

> That's odd.  Here, on Solaris 2.3, configure doesn't add an -lnsl to the
> libraries to be linked in.  I reported this a few weeks back, but it seems to
> still be happening.

Solaris 2.3 is not a very good OS, really.  I'd upgrade to 2.5 or better 
yet directly to 2.51.

Tom
                                           ?
                                         ''~``
                                        ( o o )
+----------------------------------.oooO--(_)--Oooo.------------------------+

   mailto:tkaczma@luc.edu
                           http://orion.it.luc.edu/~tkaczma
                                     .oooO                  (312) 512-7302
                                     (   )   Oooo.
+-------------------------------------\ (----(   )--------------------------+
                                       \_)    ) / 
                                             (_/

Re: zsh-3.0.0 installed in the US

[Andrew Cosgriff]

** "TK" == Tom Kaczmarski <tkaczma@math.luc.edu> writes:

TK> On 16 Aug 1996, Andrew Cosgriff wrote:
ajc> That's odd.  Here, on Solaris 2.3, configure doesn't add an -lnsl to the
ajc> libraries to be linked in.  I reported this a few weeks back, but it
ajc> seems to still be happening.

TK> Solaris 2.3 is not a very good OS, really.  I'd upgrade to 2.5 or better
TK> yet directly to 2.51.

Well, I appreciate the comment, but it's hardly a solution to the problem,
since some of us can't go upgrading our OSes willy-nilly, and besides that,
zsh used to compile just fine before before the pre-3.0 releases.

Solaris 2.3 isn't *that* bad - we've got production systems using it quite
happily, and as much as i'd like to see them on 2.5.1, it hasn't made it into
our development schedules just yet.

(oh, and yes, i do have a few 2.5 and 2.5.1 machines, but i haven't tried
building zsh on them yet...)

Andrew.
-- 
 - Andrew J Cosgriff - ajc@bing.wattle.id.au -          Mobile : +61-14-856-122
 SysAdmin / Support Dude, UNICO Computer Systems    PGP & MIME ok and preferred
                 "The Word is a virus" (William S. Burroughs)

Re: zsh-3.0.0 installed in the US

[Tom Kaczmarski]

On 20 Aug 1996, Andrew Cosgriff wrote:

> Well, I appreciate the comment, but it's hardly a solution to the problem,
> since some of us can't go upgrading our OSes willy-nilly, and besides that,
> zsh used to compile just fine before before the pre-3.0 releases.

Hmmmm, if you can't upgrade OSes "willy nilly" you probably shouldn't be 
upgradink shells by the same token.

> Solaris 2.3 isn't *that* bad - we've got production systems using it quite
> happily, and as much as i'd like to see them on 2.5.1, it hasn't made it into
> our development schedules just yet.

It takes a couple minutes per machine given that you have a fast CDROM.

> (oh, and yes, i do have a few 2.5 and 2.5.1 machines, but i haven't tried
> building zsh on them yet...)

It should go without a snag.  We don't have 2.5.1 yet because we haven't 
run into a need for it yet.  We'll probably upgrade sometime when we have 
nothing better to do. ;)  We != luc.edu.

I hope you find your answer;

Tom

                                           ?
                                         ''~``
                                        ( o o )
+----------------------------------.oooO--(_)--Oooo.------------------------+

   mailto:tkaczma@luc.edu
                           http://orion.it.luc.edu/~tkaczma
                                     .oooO                  (312) 512-7302
                                     (   )   Oooo.
+-------------------------------------\ (----(   )--------------------------+
                                       \_)    ) / 
                                             (_/

Re: zsh-3.0.0 released

[John Harres]

After installing 3.0.0, I noticed that I had a core file in the zsh-3.0.0
directory.  I didn't notice any core dumps occuring.  The zsh that was built
works just fine.  Is this normal?  Desirable?

I'm running Digital UNIX 3.2.

John Harres
harres@uwyo.edu

Re: zsh-3.0.0 released

[Richard Coleman]

> After installing 3.0.0, I noticed that I had a core file in the zsh-3.0.0
> directory.  I didn't notice any core dumps occuring.  The zsh that was built
> works just fine.  Is this normal?  Desirable?

Do a "file core" to find out what the core is from.

rc

Re: zsh-3.0.0 released

[John Harres]

> > After installing 3.0.0, I noticed that I had a core file in the zsh-3.0.0
> > directory.  I didn't notice any core dumps occuring.  The zsh that was built
> > works just fine.  Is this normal?  Desirable?
> 
> Do a "file core" to find out what the core is from.
> 

horseman:/usr/local/src/zsh-3.0.0# file core
core:   core dump, generated from 'conftest'

Re: zsh-3.0.0 released

[Richard Coleman]

> > > After installing 3.0.0, I noticed that I had a core file in the zsh-3.0.0
> > > directory.  I didn't notice any core dumps occuring.  The zsh that was built
> > > works just fine.  Is this normal?  Desirable?
> > 
> > Do a "file core" to find out what the core is from.
> > 
> 
> horseman:/usr/local/src/zsh-3.0.0# file core
> core:   core dump, generated from 'conftest'

Looks like one of the configure tests dumped core.  It's hard to
tell who's fault that is.  I believe you can get configure to keep
a log of what it is doing.  That would help to decipher which configure
test is creating the problem.

rc

Re: zsh-3.0.0 released

[Wayne Davison]

John Harres writes:
> horseman:/usr/local/src/zsh-3.0.0# file core
> core:   core dump, generated from 'conftest'

This is quite normal on a system where tgetent doesn't accept NULL
(which is one of the configure tests).  The only problem is that
configure didn't remove the core file, which it should have done.

..wayne..

Distribution terms

[Greg J. Badros]

Hi.
  Do you, Zoltan, or does anyone else know where I can find explicit
distribution terms for Zsh.  I've looked the usual places, and not found
any information.  I'm asking permission of the FSF to use the bit of
color_ls in zsh, but we need to let them know the distribution policy.
  The closest thing I can find is in the heading of the top level
Makefile.in.  Are those the up-to-date terms and disclaimer?
  Thanks!

Greg J. Badros
gjb@cs.duke.edu
http://www.cs.duke.edu/~gjb

Re: Distribution terms

[Bart Schaefer]

On Aug 27, 10:25am, Greg J. Badros wrote:
} Subject: Distribution terms
}
}   Do you, Zoltan, or does anyone else know where I can find explicit
} distribution terms for Zsh.  I've looked the usual places, and not found
} any information.  I'm asking permission of the FSF to use the bit of
} color_ls in zsh, but we need to let them know the distribution policy.

Before you go through that hassle, perhaps we should have (a) a statement
from Zoltan on whether he thinks the patches are worth including in the
first place, and (b) a discussion on zsh-workers about that statement.

I, for one, find this to be complete fluff and would just as soon skip it.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Distribution terms

[Bruce Stephens]

> Before you go through that hassle, perhaps we should have (a) a statement
> from Zoltan on whether he thinks the patches are worth including in the
> first place, and (b) a discussion on zsh-workers about that statement.

In their present state, they shouldn't be added, but if cleaned up so
they're independent of list_types, I don't see why not.  list_types
suggests that there's some equivalence between listing files for
completion and listing files generally, so perhaps a better solution
(which wouldn't involve much extra code) would be to allow users to
execute a command on lists of completions, so I could just pass it to
ls.  Does anybody see anything wrong with that?  (Potentially, one
could then get rid of list_types in favour of the user providing "ls
-F", but there are obvious speed problems with that.)

> I, for one, find this to be complete fluff and would just as soon skip it.

It's certainly fluff, but I think it's quite pretty.  I'd just as soon
do it differently, though: I'd be happy for zsh to use an external ls.
Or, one day, when we have dynamic loading in zsh like ksh93, perhaps a
dynamically loaded ls function that I've extracted from fileutils.

--
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: Distribution terms

[Greg J. Badros]

On Tue, 27 Aug 1996, Bruce Stephens wrote:

> > Before you go through that hassle, perhaps we should have (a) a statement
> > from Zoltan on whether he thinks the patches are worth including in the
> > first place, and (b) a discussion on zsh-workers about that statement.

Agreed, but I believe in doing things in parallel, especially when it's
not that much trouble.  Peter Anvin, author of the patch, has no problem
with its being used in Zsh.  I'm still waiting for word from RMS as the
FSF says the copyright has been assigned to them. 

> In their present state, they shouldn't be added, but if cleaned up so
> they're independent of list_types, I don't see why not.  list_types

They are now-- see
http://www.cs.duke.edu/~gjb/patches/Zsh3-ColorPostPrompt.patch

Of course, there are several other things in this patch, including my
PostPrompt mechanism (nobody has said anything about that?  Anybody like
this idea?), a lame (commented out) attempt at dynamic abbreviation
completion, and some word movement zle fns.

> suggests that there's some equivalence between listing files for
> completion and listing files generally, so perhaps a better solution
> (which wouldn't involve much extra code) would be to allow users to
> execute a command on lists of completions, so I could just pass it to
> ls.  Does anybody see anything wrong with that?  (Potentially, one
> could then get rid of list_types in favour of the user providing "ls
> -F", but there are obvious speed problems with that.)

To me, the colorized completion in a shell is where the color-ls patch has
always belonged.  *Interactive* use is what the color-ls patch is for, and
that is what a lot of the features of zsh are about.  Launching an
external command is slow, like you said, and makes zsh more dependent on
other software.

> 
> > I, for one, find this to be complete fluff and would just as soon skip it.
> 
> It's certainly fluff, but I think it's quite pretty.  I'd just as soon
> do it differently, though: I'd be happy for zsh to use an external ls.
> Or, one day, when we have dynamic loading in zsh like ksh93, perhaps a
> dynamically loaded ls function that I've extracted from fileutils.
> --
> Bruce Stephens			| email: B.Stephens@math.ruu.nl
> (rest of sig deleted)

I even question whether it's totally fluff.  One especially useful feature
is the colorizing of orphaned symlinks-- true color_ls will do this too,
but I look at directories as much, if not more, from the completionn menu
as from a ls process.  This lets me notice problems with my file system
early.

Even if it is fluff, it's pretty useful fluff, and it's a hard line to
draw to stop featuritis, while adding good features.

Greg J. Badros
gjb@cs.duke.edu
http://www.cs.duke.edu/~gjb

Re: Distribution terms

[Bart Schaefer]

On Aug 27,  1:04pm, Greg J. Badros wrote:
} Subject: Re: Distribution terms
}
} PostPrompt mechanism (nobody has said anything about that?  Anybody like
} this idea?)

My only reaction is that I'd never want the timeout set to anything
greater than zero.  Zsh has no business waking up and blatting output
to my terminal in the midst of output that some other program may be
generating.  The potential for confusion is too great; I don't need,
for example, a chunk of "make" output lopped out of my xterm window and
stuffed into the title bar because zsh was trying to postprompt at the
same instant make was echoing its next command.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Distribution terms

[Zefram]

>Before you go through that hassle, perhaps we should have (a) a statement
>from Zoltan on whether he thinks the patches are worth including in the
>first place, and (b) a discussion on zsh-workers about that statement.
>
>I, for one, find this to be complete fluff and would just as soon skip it.

Absolutely.  There's no need for this to be built in to zsh, and it
wouldn't pull its weight if it were.  Few people would use it (I can't
stand coloured ls output) -- it'd be quite a lot of useless code.

Much better would be a generalisation of completion listing so that one
could have a shell function statting each file via [[ -S $foo ]] etc.,
and outputting the colour codes itself.  It would mean a few more
syscalls (possibly), but (a) it's infinitely configurable, (b) it
doesn't require much more code, (c) overhead is almost zero for people
not using it.

-zefram

Re: Distribution terms

[Zoltan Hidvegi]

> }   Do you, Zoltan, or does anyone else know where I can find explicit
> } distribution terms for Zsh.  I've looked the usual places, and not found
> } any information.  I'm asking permission of the FSF to use the bit of
> } color_ls in zsh, but we need to let them know the distribution policy.
> 
> Before you go through that hassle, perhaps we should have (a) a statement
> from Zoltan on whether he thinks the patches are worth including in the
> first place, and (b) a discussion on zsh-workers about that statement.

As Richard wrote the copyright policy can be found in each C source file.
I'll extract it to a separate COPYING file and add that that copiright
notice holds for all included file except where there is a different
copyright note in the file (i.e. COPYING will say that zsh is copyrighted
by P.F. but Makefiles, configure.in etc. are copyrighted by Richard.  I do
not know who copyrights the texinfo documentation.  It comes mostly from
the manual so PF maybe.  I do not know anything about copyright law.  If
one expert could write a good COPYING file based on the comments in C files
and the general ideas above I would happily include it in the distribution.

And about colorizes lists: first there will be a zsh-3.0.1 release.  It
will definitely not be added before that.  And in zsh-3.1 we have to find
out a portable way to use dynamically loadable modules.  After that anyone
can write a plug-in for zsh and can implement any feature he wants.  But
such features should not blow up zsh.  It would be a good idea to better
modularise the existing zsh code, make a few things optional (fo rexample
zle and completion).  I do not know how much is the ovehead caused by a big
executable.  When zsh is used as a scipt interpreter on a demand-paged
system only the parts necessary run a script will be loaded so it may not
give any real improvement.

Zoltan

future of zsh

[Richard Coleman]

> And about colorizes lists: first there will be a zsh-3.0.1 release.  It
> will definitely not be added before that.  And in zsh-3.1 we have to find
> out a portable way to use dynamically loadable modules.  After that anyone
> can write a plug-in for zsh and can implement any feature he wants.  But
> such features should not blow up zsh.  It would be a good idea to better
> modularise the existing zsh code, make a few things optional (fo rexample
> zle and completion).  I do not know how much is the ovehead caused by a big
> executable.  When zsh is used as a scipt interpreter on a demand-paged
> system only the parts necessary run a script will be loaded so it may not
> give any real improvement.

Aaahhh... time for the inevitable "future of zsh" discusion.  We haven't
had one of those in a while.  But before everyone sends there "We need to
add feature X!" requests, I would like to say a few things.

I think Zoltan's idea of loadable modules is a good idea.  This
would give us the infrastructure to add lots of features, without
bloating the code any more.  Hopefully, some of the current functionality
could be moved out of the zsh core, and into modules such as this.  But
before everyone starts rejoicing at this idea, realize it is non-trivial
and will require work, and will greatly complicate parts of the code.

As to zle and completion, it would be great if this could be moved
to a module, or to a seperate library.  I had similar ideas when I was
maintainer.  Unfortunately, zle and completion use so many of the
internal data structures (just about all of them actually), this would be
very difficult.  I believe a better idea is to move some of the
internals of the completion code into the hash table code.  This was
part of the motivation when I rewrote the hash table code.  Essentially
each object would know how to complete itself.  Again, this is non-trivial,
but a worthwhile goal.  I believe that a general mechanism for hash table
searching would simplify both the completion code and the spell checking
code.

zsh 3.0 is a great increase in modularity over previous version, as well
as being much more maintainable (take a look at the zsh 2.5.03 code if
you don't believe me).  But I believe this is a process that should
continue.  In particular, the exec.c code is still somewhat of a mess.  If
I find some time, I will probably do some work on this myself.

Also, I wanted to say I think zsh has made great progress over the last
couple of years.  Thanks to all who worked on it.

rc

Re: zsh: future and loadable modules

[Chip Salzenberg]

According to Richard Coleman:
> before everyone starts rejoicing at this idea, realize it is non-trivial
> and will require work, and will greatly complicate parts of the code.

It needn't be too hard.  Consider fvwm2 and Perl; both use loadable
modules to excellent effect.  In particular, Perl's extension system
is easy to use and very powerful.

That said, I would consider it important to put all /bin/sh behavior
in the base executable.  Otherwise you could end up with a seriously
broken system and no way to recover.

> Also, I wanted to say I think zsh has made great progress over the last
> couple of years.  Thanks to all who worked on it.

Ditto.
-- 
Chip Salzenberg             - a.k.a. -             <chip@atlantic.net>
    "I wanted to play hopscotch with the impenetrable mystery of
   existence, but he stepped in a wormhole and had to go in early."
         -- Crow T. Robot, _Mystery_Science_Theater_3000_

Re: zsh: future and loadable modules

[Bruce Stephens]

> It needn't be too hard.  Consider fvwm2 and Perl; both use loadable
> modules to excellent effect.  In particular, Perl's extension system
> is easy to use and very powerful.

fvwm2 (unless it's changed since the last version I got) spawns
modules and communicates with them using pipes.  It works just fine
for fvwm, but I suspect it would have limited use in zsh.

Tcl7.5 is another example worth looking at: it does dynamic loading on
a few systems, and has autoconf support for it.

Re: future of zsh

[Zoltan Hidvegi]

Richard wrote:
> As to zle and completion, it would be great if this could be moved
> to a module, or to a seperate library.  I had similar ideas when I was
> maintainer.  Unfortunately, zle and completion use so many of the
> internal data structures (just about all of them actually), this would be
> very difficult.  I believe a better idea is to move some of the

That's not a problem.  A mudule can use any zsh internal function/variable
etc.  The important thing is that the main code should not use anything
from the module.  The main part of zsh does not use zle + completion as I
know except the read builtin and the compctl builtin.  The later should
probably be moved into a separate file.

Adding loadable modules on an elf system is trivial (I have already done
that on linux) and it is probably not difficult on other systems which
support dlopen/dlclose/dlsym.  On systems modules cannot be statically
linked to zsh as a compile-time option.  The difficult part is to write
configure tests about how to compile and link dynamic modules and figure
out a consistent interface.

> internals of the completion code into the hash table code.  This was
> part of the motivation when I rewrote the hash table code.  Essentially
> each object would know how to complete itself.  Again, this is non-trivial,
> but a worthwhile goal.  I believe that a general mechanism for hash table
> searching would simplify both the completion code and the spell checking
> code.

Yes, it may be doable.  The zsh code gradually becomes more and more
object-orientated.

> zsh 3.0 is a great increase in modularity over previous version, as well
> as being much more maintainable (take a look at the zsh 2.5.03 code if
> you don't believe me).  But I believe this is a process that should

Oh, I believe it.  I've seen parts of it.

> continue.  In particular, the exec.c code is still somewhat of a mess.  If
> I find some time, I will probably do some work on this myself.

That would be great.  When you do that do not forget to use a profiler.
Sometimes I think I understand most of exec.c but then I wake up.

Zoltan

Re: Distribution terms

[Zefram]

>                                           And in zsh-3.1 we have to find
>out a portable way to use dynamically loadable modules.  After that anyone
>can write a plug-in for zsh and can implement any feature he wants.  But
>such features should not blow up zsh.

I doubt that you'll find a way to do dynamic loading on every Unix.  It
might be best to simply restrict such features to Unices where the ELF
library is available (dlopen(), etc.) -- this would avoid a lot of
complication.


>                                       It would be a good idea to better
>modularise the existing zsh code, make a few things optional (fo rexample
>zle and completion).

I think it would be a good idea to have a configure-time option to
exclude ZLE, even where it can't be dynamically loaded.  Simple
conditional compilation could do this.  We might also want to consider
a configuration option to build a restricted shell -- this is a major
feature that most other shells already have.

Another thing we might want to do is to optionally have basic
file-manipulation commands (mv, rm, etc.) as builtins.  Maybe some
administration commands (mount, mknod) too.  The purpose of this would
be that we could have a statically-linked zsh in /sbin for when the
system is hosed.  (I'd support making sync a builtin even in the
standard version.)

>                      I do not know how much is the ovehead caused by a big
>executable.  When zsh is used as a scipt interpreter on a demand-paged
>system only the parts necessary run a script will be loaded so it may not
>give any real improvement.

There's not much speed improvement, and actually loading a module
separate from the executable will cause a penalty.  This penalty won't
be a problem unless it is incurred on every invocation -- we should
definitely avoid doing this.

-zefram

Re: Distribution terms

[Zoltan Hidvegi]

> >                      I do not know how much is the ovehead caused by a big
> >executable.  When zsh is used as a scipt interpreter on a demand-paged
> >system only the parts necessary run a script will be loaded so it may not
> >give any real improvement.
> 
> There's not much speed improvement, and actually loading a module
> separate from the executable will cause a penalty.  This penalty won't
> be a problem unless it is incurred on every invocation -- we should
> definitely avoid doing this.

I meant memory usage and startup time improvements not speed imporovements
and only for scripts which do not load any modules.

Adding module support will increase the size of zsh because the binary
should carry the symbol table but that should not affect startup time of
memory usage.

Zoltan

Re: Distribution terms

[Richard Coleman]

> Hi.
>   Do you, Zoltan, or does anyone else know where I can find explicit
> distribution terms for Zsh.  I've looked the usual places, and not found
> any information.  I'm asking permission of the FSF to use the bit of
> color_ls in zsh, but we need to let them know the distribution policy.
>   The closest thing I can find is in the heading of the top level
> Makefile.in.  Are those the up-to-date terms and disclaimer?

The distribution terms for the source code are given at the top of each
file in Src.  Essentially, all the C code is copyrighted by Paul, while
the Makefiles, and config stuff are copyrighted by me.  The copyright
notice is a Berkeley style copyright that I got from the Tcl/Tk
distribution (this is sometimes called the Ousterhout license), and
Paul agreed to allow me to distribute zsh under those terms.  He
specifically did not want to use the GPL.

The man pages do not have a copyright notice, but should be considered
to be copyrighted by Paul as well.  [ Zoltan, can you add this notice? ]

rc