* zsh-3.0.0 released @ 1996-08-15 18:17 Zoltan Hidvegi 1996-08-15 18:57 ` zsh-3.0.0 installed in the US Tom Kaczmarski ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Zoltan Hidvegi @ 1996-08-15 18:17 UTC (permalink / raw) To: Zsh workers list -----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----- ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 installed in the US 1996-08-15 18:17 zsh-3.0.0 released Zoltan Hidvegi @ 1996-08-15 18:57 ` Tom Kaczmarski 1996-08-16 4:18 ` Andrew Cosgriff 1996-08-15 19:56 ` zsh-3.0.0 released John Harres 1996-08-27 14:25 ` Distribution terms Greg J. Badros 2 siblings, 1 reply; 25+ messages in thread From: Tom Kaczmarski @ 1996-08-15 18:57 UTC (permalink / raw) To: Zsh workers list 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. +-------------------------------------\ (----( )--------------------------+ \_) ) / (_/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 installed in the US 1996-08-15 18:57 ` zsh-3.0.0 installed in the US Tom Kaczmarski @ 1996-08-16 4:18 ` Andrew Cosgriff 1996-08-16 11:55 ` Tom Kaczmarski 0 siblings, 1 reply; 25+ messages in thread From: Andrew Cosgriff @ 1996-08-16 4:18 UTC (permalink / raw) To: zsh-workers ** "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" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 installed in the US 1996-08-16 4:18 ` Andrew Cosgriff @ 1996-08-16 11:55 ` Tom Kaczmarski 1996-08-20 1:32 ` Andrew Cosgriff 0 siblings, 1 reply; 25+ messages in thread From: Tom Kaczmarski @ 1996-08-16 11:55 UTC (permalink / raw) To: Andrew Cosgriff; +Cc: zsh-workers 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. +-------------------------------------\ (----( )--------------------------+ \_) ) / (_/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 installed in the US 1996-08-16 11:55 ` Tom Kaczmarski @ 1996-08-20 1:32 ` Andrew Cosgriff 1996-08-20 12:55 ` Tom Kaczmarski 0 siblings, 1 reply; 25+ messages in thread From: Andrew Cosgriff @ 1996-08-20 1:32 UTC (permalink / raw) To: zsh-workers ** "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) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 installed in the US 1996-08-20 1:32 ` Andrew Cosgriff @ 1996-08-20 12:55 ` Tom Kaczmarski 0 siblings, 0 replies; 25+ messages in thread From: Tom Kaczmarski @ 1996-08-20 12:55 UTC (permalink / raw) To: Andrew Cosgriff; +Cc: zsh-workers 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. +-------------------------------------\ (----( )--------------------------+ \_) ) / (_/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 released 1996-08-15 18:17 zsh-3.0.0 released Zoltan Hidvegi 1996-08-15 18:57 ` zsh-3.0.0 installed in the US Tom Kaczmarski @ 1996-08-15 19:56 ` John Harres 1996-08-15 20:14 ` Richard Coleman 1996-08-27 14:25 ` Distribution terms Greg J. Badros 2 siblings, 1 reply; 25+ messages in thread From: John Harres @ 1996-08-15 19:56 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: Zsh workers list 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 released 1996-08-15 19:56 ` zsh-3.0.0 released John Harres @ 1996-08-15 20:14 ` Richard Coleman 1996-08-15 20:27 ` John Harres 0 siblings, 1 reply; 25+ messages in thread From: Richard Coleman @ 1996-08-15 20:14 UTC (permalink / raw) To: John Harres; +Cc: Zsh workers list > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 released 1996-08-15 20:14 ` Richard Coleman @ 1996-08-15 20:27 ` John Harres 1996-08-15 21:22 ` Richard Coleman 1996-08-15 21:35 ` Wayne Davison 0 siblings, 2 replies; 25+ messages in thread From: John Harres @ 1996-08-15 20:27 UTC (permalink / raw) To: Richard Coleman; +Cc: Zsh workers list > > 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' ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 released 1996-08-15 20:27 ` John Harres @ 1996-08-15 21:22 ` Richard Coleman 1996-08-15 21:35 ` Wayne Davison 1 sibling, 0 replies; 25+ messages in thread From: Richard Coleman @ 1996-08-15 21:22 UTC (permalink / raw) To: John Harres; +Cc: Zsh workers list > > > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh-3.0.0 released 1996-08-15 20:27 ` John Harres 1996-08-15 21:22 ` Richard Coleman @ 1996-08-15 21:35 ` Wayne Davison 1 sibling, 0 replies; 25+ messages in thread From: Wayne Davison @ 1996-08-15 21:35 UTC (permalink / raw) To: John Harres; +Cc: Richard Coleman, Zsh workers list 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.. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Distribution terms 1996-08-15 18:17 zsh-3.0.0 released Zoltan Hidvegi 1996-08-15 18:57 ` zsh-3.0.0 installed in the US Tom Kaczmarski 1996-08-15 19:56 ` zsh-3.0.0 released John Harres @ 1996-08-27 14:25 ` Greg J. Badros 1996-08-27 15:28 ` Bart Schaefer 1996-08-27 16:37 ` Richard Coleman 2 siblings, 2 replies; 25+ messages in thread From: Greg J. Badros @ 1996-08-27 14:25 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: Zsh workers list 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 14:25 ` Distribution terms Greg J. Badros @ 1996-08-27 15:28 ` Bart Schaefer 1996-08-27 15:37 ` Bruce Stephens ` (2 more replies) 1996-08-27 16:37 ` Richard Coleman 1 sibling, 3 replies; 25+ messages in thread From: Bart Schaefer @ 1996-08-27 15:28 UTC (permalink / raw) To: Greg J. Badros, Zoltan Hidvegi, zsh-workers 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" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 15:28 ` Bart Schaefer @ 1996-08-27 15:37 ` Bruce Stephens 1996-08-27 17:04 ` Greg J. Badros 1996-08-27 19:04 ` Zefram 1996-08-27 19:25 ` Zoltan Hidvegi 2 siblings, 1 reply; 25+ messages in thread From: Bruce Stephens @ 1996-08-27 15:37 UTC (permalink / raw) To: schaefer > 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 | ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 15:37 ` Bruce Stephens @ 1996-08-27 17:04 ` Greg J. Badros 1996-08-27 18:58 ` Bart Schaefer 0 siblings, 1 reply; 25+ messages in thread From: Greg J. Badros @ 1996-08-27 17:04 UTC (permalink / raw) To: Bruce Stephens; +Cc: schaefer, zsh-workers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 17:04 ` Greg J. Badros @ 1996-08-27 18:58 ` Bart Schaefer 0 siblings, 0 replies; 25+ messages in thread From: Bart Schaefer @ 1996-08-27 18:58 UTC (permalink / raw) To: Greg J. Badros; +Cc: zsh-workers 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" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 15:28 ` Bart Schaefer 1996-08-27 15:37 ` Bruce Stephens @ 1996-08-27 19:04 ` Zefram 1996-08-27 19:25 ` Zoltan Hidvegi 2 siblings, 0 replies; 25+ messages in thread From: Zefram @ 1996-08-27 19:04 UTC (permalink / raw) To: schaefer; +Cc: gjb, hzoli, zsh-workers >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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 15:28 ` Bart Schaefer 1996-08-27 15:37 ` Bruce Stephens 1996-08-27 19:04 ` Zefram @ 1996-08-27 19:25 ` Zoltan Hidvegi 1996-08-27 19:53 ` future of zsh Richard Coleman 1996-08-27 20:20 ` Distribution terms Zefram 2 siblings, 2 replies; 25+ messages in thread From: Zoltan Hidvegi @ 1996-08-27 19:25 UTC (permalink / raw) To: schaefer; +Cc: gjb, zsh-workers > } 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* future of zsh 1996-08-27 19:25 ` Zoltan Hidvegi @ 1996-08-27 19:53 ` Richard Coleman 1996-08-27 16:32 ` zsh: future and loadable modules Chip Salzenberg 1996-08-27 20:23 ` future of zsh Zoltan Hidvegi 1996-08-27 20:20 ` Distribution terms Zefram 1 sibling, 2 replies; 25+ messages in thread From: Richard Coleman @ 1996-08-27 19:53 UTC (permalink / raw) To: zsh-workers > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh: future and loadable modules 1996-08-27 19:53 ` future of zsh Richard Coleman @ 1996-08-27 16:32 ` Chip Salzenberg 1996-08-28 9:03 ` Bruce Stephens 1996-08-27 20:23 ` future of zsh Zoltan Hidvegi 1 sibling, 1 reply; 25+ messages in thread From: Chip Salzenberg @ 1996-08-27 16:32 UTC (permalink / raw) To: Richard Coleman; +Cc: zsh-workers 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_ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: zsh: future and loadable modules 1996-08-27 16:32 ` zsh: future and loadable modules Chip Salzenberg @ 1996-08-28 9:03 ` Bruce Stephens 0 siblings, 0 replies; 25+ messages in thread From: Bruce Stephens @ 1996-08-28 9:03 UTC (permalink / raw) To: zsh-workers > 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: future of zsh 1996-08-27 19:53 ` future of zsh Richard Coleman 1996-08-27 16:32 ` zsh: future and loadable modules Chip Salzenberg @ 1996-08-27 20:23 ` Zoltan Hidvegi 1 sibling, 0 replies; 25+ messages in thread From: Zoltan Hidvegi @ 1996-08-27 20:23 UTC (permalink / raw) To: Richard Coleman; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 19:25 ` Zoltan Hidvegi 1996-08-27 19:53 ` future of zsh Richard Coleman @ 1996-08-27 20:20 ` Zefram 1996-08-27 20:32 ` Zoltan Hidvegi 1 sibling, 1 reply; 25+ messages in thread From: Zefram @ 1996-08-27 20:20 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: schaefer, gjb, zsh-workers > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 20:20 ` Distribution terms Zefram @ 1996-08-27 20:32 ` Zoltan Hidvegi 0 siblings, 0 replies; 25+ messages in thread From: Zoltan Hidvegi @ 1996-08-27 20:32 UTC (permalink / raw) To: Zefram; +Cc: schaefer, gjb, zsh-workers > > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Distribution terms 1996-08-27 14:25 ` Distribution terms Greg J. Badros 1996-08-27 15:28 ` Bart Schaefer @ 1996-08-27 16:37 ` Richard Coleman 1 sibling, 0 replies; 25+ messages in thread From: Richard Coleman @ 1996-08-27 16:37 UTC (permalink / raw) To: Greg J. Badros; +Cc: zsh-workers > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~1996-08-28 9:11 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-08-15 18:17 zsh-3.0.0 released Zoltan Hidvegi 1996-08-15 18:57 ` zsh-3.0.0 installed in the US Tom Kaczmarski 1996-08-16 4:18 ` Andrew Cosgriff 1996-08-16 11:55 ` Tom Kaczmarski 1996-08-20 1:32 ` Andrew Cosgriff 1996-08-20 12:55 ` Tom Kaczmarski 1996-08-15 19:56 ` zsh-3.0.0 released John Harres 1996-08-15 20:14 ` Richard Coleman 1996-08-15 20:27 ` John Harres 1996-08-15 21:22 ` Richard Coleman 1996-08-15 21:35 ` Wayne Davison 1996-08-27 14:25 ` Distribution terms Greg J. Badros 1996-08-27 15:28 ` Bart Schaefer 1996-08-27 15:37 ` Bruce Stephens 1996-08-27 17:04 ` Greg J. Badros 1996-08-27 18:58 ` Bart Schaefer 1996-08-27 19:04 ` Zefram 1996-08-27 19:25 ` Zoltan Hidvegi 1996-08-27 19:53 ` future of zsh Richard Coleman 1996-08-27 16:32 ` zsh: future and loadable modules Chip Salzenberg 1996-08-28 9:03 ` Bruce Stephens 1996-08-27 20:23 ` future of zsh Zoltan Hidvegi 1996-08-27 20:20 ` Distribution terms Zefram 1996-08-27 20:32 ` Zoltan Hidvegi 1996-08-27 16:37 ` Richard Coleman
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).