* zsh 5.0.2-test-1 is available @ 2013-11-06 20:23 Peter Stephenson 2013-11-06 21:57 ` Phil Pennock 2013-11-07 15:33 ` Axel Beckert 0 siblings, 2 replies; 16+ messages in thread From: Peter Stephenson @ 2013-11-06 20:23 UTC (permalink / raw) To: Zsh Users I've uploaded a test version 5.0.2-test-1 prior to releasing 4.0.3. You'll find it at http://www.zsh.org/pub/development or ftp://ftp.zsh.org/pub/development. It's also tagged in git as zsh-5.0.2-test-1 if you don't mind building from scratch. I don't think anything much configurational has changed recently, so I hope this won't cause compilation problems. Please let me know if you encounter anything unexpected. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-06 20:23 zsh 5.0.2-test-1 is available Peter Stephenson @ 2013-11-06 21:57 ` Phil Pennock 2013-11-07 15:33 ` Axel Beckert 1 sibling, 0 replies; 16+ messages in thread From: Phil Pennock @ 2013-11-06 21:57 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users On 2013-11-06 at 20:23 +0000, Peter Stephenson wrote: > I've uploaded a test version 5.0.2-test-1 prior to releasing 4.0.3. ITYM 5.0.3. :) > You'll find it at http://www.zsh.org/pub/development or > ftp://ftp.zsh.org/pub/development. Built with: ./configure --prefix=/opt/zshdev \ --enable-pcre --enable-cap --enable-multibyte --enable-dynamic \ --enable-libs="-lncurses" --with-tcsetpgrp DL_EXT=bundle on MacOS 10.8.5 with XCode 4.6.3; I'm avoiding the newer ones for now, waiting for 10.9.1, will update XCode then. (ncurses came from MacPorts, I think) Compiles cleanly; "make check" runs without issues. 42 successful test scripts, 0 failures, 0 skipped -Phil ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-06 20:23 zsh 5.0.2-test-1 is available Peter Stephenson 2013-11-06 21:57 ` Phil Pennock @ 2013-11-07 15:33 ` Axel Beckert 2013-11-07 16:05 ` Peter Stephenson 1 sibling, 1 reply; 16+ messages in thread From: Axel Beckert @ 2013-11-07 15:33 UTC (permalink / raw) To: zsh-users Hi, On Wed, Nov 06, 2013 at 08:23:21PM +0000, Peter Stephenson wrote: > I've uploaded a test version 5.0.2-test-1 prior to releasing 4.0.3. > You'll find it at http://www.zsh.org/pub/development or > ftp://ftp.zsh.org/pub/development. > > It's also tagged in git as zsh-5.0.2-test-1 if you don't mind building > from scratch. A Debian package based on 5.0.2 packaging plus 5.0.2-test-1 sources builds fine. But when using it with my setup, it issues the following error message: /home/abe/.zsh/grml-etc-core/etc/zsh/zshrc:zmodload:984: failed to add builtin `zstat' /usr/lib/x86_64-linux-gnu/zsh/5.0.2-test-1/zsh/stat.so exists: -rw-r--r-- 1 root root 14904 Nov 7 15:09 /usr/lib/x86_64-linux-gnu/zsh/5.0.2-test-1/zsh/stat.so The corresponding code lines are: 982 # autoload zsh modules when they are referenced 983 if is4 ; then 984 zmodload -a zsh/stat zstat 985 zmodload -a zsh/zpty zpty 986 zmodload -ap zsh/mapfile mapfile 987 fi The other two zmodload lines (985 + 986) work fine, only 984 throws this error reproducibly. Otherwise zsh 5.0.2-test-1 works fine on a first glance. Will continue to use it on my development system to see if anything further pops up. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe@deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-07 15:33 ` Axel Beckert @ 2013-11-07 16:05 ` Peter Stephenson 2013-11-07 19:18 ` Phil Pennock 0 siblings, 1 reply; 16+ messages in thread From: Peter Stephenson @ 2013-11-07 16:05 UTC (permalink / raw) To: zsh-users On Thu, 07 Nov 2013 16:33:15 +0100 Axel Beckert <abe@deuxchevaux.org> wrote: > /home/abe/.zsh/grml-etc-core/etc/zsh/zshrc:zmodload:984: failed to add builtin `zstat' That means the module loaded, but there was already a conflicting builtin named "zstat" --- at least that's the only likely reason for that error I can see, unless the builtin table is very badly messed up. pws ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-07 16:05 ` Peter Stephenson @ 2013-11-07 19:18 ` Phil Pennock 2013-11-08 1:36 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: Phil Pennock @ 2013-11-07 19:18 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 2013-11-07 at 16:05 +0000, Peter Stephenson wrote: > On Thu, 07 Nov 2013 16:33:15 +0100 > Axel Beckert <abe@deuxchevaux.org> wrote: > > /home/abe/.zsh/grml-etc-core/etc/zsh/zshrc:zmodload:984: failed to add builtin `zstat' > > That means the module loaded, but there was already a conflicting > builtin named "zstat" --- at least that's the only likely reason > for that error I can see, unless the builtin table is very badly messed > up. So there is a regression here. My startup files do: zmodload -F zsh/stat b:zstat With that run, `zmodload` does *not* list the zsh/stat module, in either 5.0.2-test-1 or 5.0.2. However, If I then run `zmodload -a zsh/stat zstat` then in 5.0.2 it succeeds silently, but in 5.0.2-test-1 I see the error which Axel reports. -Phil ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-07 19:18 ` Phil Pennock @ 2013-11-08 1:36 ` Bart Schaefer 2013-11-08 3:16 ` Axel Beckert 2013-11-08 7:16 ` Phil Pennock 0 siblings, 2 replies; 16+ messages in thread From: Bart Schaefer @ 2013-11-08 1:36 UTC (permalink / raw) To: zsh-users On Nov 7, 2:18pm, Phil Pennock wrote: } } My startup files do: } } zmodload -F zsh/stat b:zstat } } With that run, `zmodload` does *not* list the zsh/stat module, in either } 5.0.2-test-1 or 5.0.2. } } However, If I then run `zmodload -a zsh/stat zstat` then in 5.0.2 it } succeeds silently, but in 5.0.2-test-1 I see the error which Axel } reports. I just checked out commit daa828bc51b48110f0a584fa2b74895d2cc761c1 and compiled it. I get the same error message in 5.0.2 as in -test-1. schaefer<501> zmodload -F zsh/stat b:zstat schaefer<502> zmodload -a zsh/stat zstat zmodload: failed to add builtin `zstat' schaefer<503> print $ZSH_VERSION $ZSH_PATCHLEVEL 5.0.2 1.5778 In fact: burner% zmodload -F zsh/stat b:zstat burner% zmodload -a zsh/stat zstat zmodload: failed to add builtin `zstat' burner% print $ZSH_VERSION $ZSH_PATCHLEVEL 4.3.17 Debian So I don't know why you weren't getting the error message before, but it's not a code regression. Aside: This is a bit weird: torch% zmodload -a zsh/stat zmodload: zsh/stat: `/' is illegal in a builtin zmodload not checking that it has the correct number of arguments? -- Barton E. Schaefer ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 1:36 ` Bart Schaefer @ 2013-11-08 3:16 ` Axel Beckert 2013-11-08 6:01 ` Bart Schaefer 2013-11-08 7:16 ` Phil Pennock 1 sibling, 1 reply; 16+ messages in thread From: Axel Beckert @ 2013-11-08 3:16 UTC (permalink / raw) To: zsh-users Hi, On Thu, Nov 07, 2013 at 05:36:27PM -0800, Bart Schaefer wrote: > On Nov 7, 2:18pm, Phil Pennock wrote: > } My startup files do: > } > } zmodload -F zsh/stat b:zstat > } > } With that run, `zmodload` does *not* list the zsh/stat module, in either > } 5.0.2-test-1 or 5.0.2. > } > } However, If I then run `zmodload -a zsh/stat zstat` then in 5.0.2 it > } succeeds silently, but in 5.0.2-test-1 I see the error which Axel > } reports. > > I just checked out commit daa828bc51b48110f0a584fa2b74895d2cc761c1 and > compiled it. I get the same error message in 5.0.2 as in -test-1. > > schaefer<501> zmodload -F zsh/stat b:zstat > schaefer<502> zmodload -a zsh/stat zstat > zmodload: failed to add builtin `zstat' > schaefer<503> print $ZSH_VERSION $ZSH_PATCHLEVEL > 5.0.2 1.5778 > > In fact: > > burner% zmodload -F zsh/stat b:zstat > burner% zmodload -a zsh/stat zstat > zmodload: failed to add builtin `zstat' > burner% print $ZSH_VERSION $ZSH_PATCHLEVEL > 4.3.17 Debian ~ → zmodload -F zsh/stat b:zstat ~ → zmodload -a zsh/stat zstat zmodload: failed to add builtin `zstat' ~ → print $ZSH_VERSION $ZSH_PATCHLEVEL 4.3.10 Debian Nevertheless I don't get that error message via my zshrc, neither with 4.3.10 (Debian Squeeze/Oldstable), 4.3.17 (Debian Wheezy/Stable) nor 5.0.2 (Debian Sid/Unstable), just 5.0.2-test-1. > So I don't know why you weren't getting the error message before, but > it's not a code regression. I suspect that Phil's and my issues are not as similar as they might look at a first glance. Ah "git grep zmodload" over my (well, grml's) zshrc shows: ~/.zsh/grml-etc-core → git grep zmodload etc/zsh/keephack:zmodload -i zsh/complist etc/zsh/zshrc: zmodload zsh/zprof etc/zsh/zshrc: zmodload -i zsh/${mod} 2>/dev/null || print "Notice: no ${mod} available :(" etc/zsh/zshrc: zmodload -a zsh/stat zstat etc/zsh/zshrc: zmodload -a zsh/zpty zpty etc/zsh/zshrc: zmodload -ap zsh/mapfile mapfile usr_share_grml/zsh/functions/Lookup/Backends/LOOKUP_be_rfc: if ! zmodload zsh/zftp ; then (Not sure if that helps.) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe@deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 3:16 ` Axel Beckert @ 2013-11-08 6:01 ` Bart Schaefer 0 siblings, 0 replies; 16+ messages in thread From: Bart Schaefer @ 2013-11-08 6:01 UTC (permalink / raw) To: zsh-users On Nov 8, 4:16am, Axel Beckert wrote: } } ~ -> zmodload -F zsh/stat b:zstat } ~ -> zmodload -a zsh/stat zstat } zmodload: failed to add builtin `zstat' } ~ -> print $ZSH_VERSION $ZSH_PATCHLEVEL } 4.3.10 Debian } } Nevertheless I don't get that error message via my zshrc, neither with } 4.3.10 (Debian Squeeze/Oldstable), 4.3.17 (Debian Wheezy/Stable) nor } 5.0.2 (Debian Sid/Unstable), just 5.0.2-test-1. Hrm. A look at grml's /etc/zsh/zshrc via github shows that these ... } etc/zsh/zshrc: zmodload zsh/zprof } etc/zsh/zshrc: zmodload -i zsh/${mod} 2>/dev/null || print "Notice: no ${mod} available :(" } etc/zsh/zshrc: zmodload -a zsh/stat zstat } etc/zsh/zshrc: zmodload -a zsh/zpty zpty } etc/zsh/zshrc: zmodload -ap zsh/mapfile mapfile ... are all protected by a test for "is4", which means they should not be getting executed by 5.0.2-test-1: is4(){ [[ $ZSH_VERSION == <4->* ]] && return 0 return 1 } Unless PWS's commit typo of 4.0.x for 5.0.x somehow extended into the $ZSH_VERSION variable? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 1:36 ` Bart Schaefer 2013-11-08 3:16 ` Axel Beckert @ 2013-11-08 7:16 ` Phil Pennock 2013-11-08 9:38 ` Peter Stephenson 1 sibling, 1 reply; 16+ messages in thread From: Phil Pennock @ 2013-11-08 7:16 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On 2013-11-07 at 17:36 -0800, Bart Schaefer wrote: > So I don't know why you weren't getting the error message before, but > it's not a code regression. I apologise, I've tracked it down. Depending upon the age of a cache file, zstat might be called at shell startup time. So it was a race, which I lost when I tested in 5.0.2-test-1. In zsh, you can call `zmodload -a zsh/stat zstat` repeatedly without an error, up until you call `zstat`. Once `zstat` has been invoked, future calls to `zmodload -a zsh/stat zstat` will spew an error and return 1. Unchanged from 5.0.2. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 7:16 ` Phil Pennock @ 2013-11-08 9:38 ` Peter Stephenson 2013-11-08 14:39 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: Peter Stephenson @ 2013-11-08 9:38 UTC (permalink / raw) To: Phil Pennock, zsh-users On Fri, 08 Nov 2013 02:16:27 -0500 Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote: > In zsh, you can call `zmodload -a zsh/stat zstat` repeatedly without an > error, up until you call `zstat`. Once `zstat` has been invoked, future > calls to `zmodload -a zsh/stat zstat` will spew an error and return 1. Right, that's always how it worked. I suspect Axel's problem is some similar clash in startup files; I can't think of another explanation that makes sense. A full set -x trace at boot looking for references to zsh/stat and zstat would probably show. I think the problem with making this silent is it's not currently trivial to check that the builtin that's there is actually the same as the one you're trying to add, so in theory it's not safe to ignore (though in practice we don't produce modules with conflicting builtins). It shouldn't be that difficult to do the check properly, though, and that ought to resolve the issue. pws ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 9:38 ` Peter Stephenson @ 2013-11-08 14:39 ` Bart Schaefer 2013-11-08 16:11 ` Peter Stephenson 0 siblings, 1 reply; 16+ messages in thread From: Bart Schaefer @ 2013-11-08 14:39 UTC (permalink / raw) To: zsh-users On Nov 8, 9:38am, Peter Stephenson wrote: } } I think the problem with making this silent is it's not currently } trivial to check that the builtin that's there is actually the same as } the one you're trying to add, so in theory it's not safe to ignore If you want to ignore it, "zmodload -ia zsh/stat zstat" works. I don't think there's any reason to make -i obsolete in this case. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 14:39 ` Bart Schaefer @ 2013-11-08 16:11 ` Peter Stephenson 2013-11-09 2:11 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: Peter Stephenson @ 2013-11-08 16:11 UTC (permalink / raw) To: zsh-users On Fri, 08 Nov 2013 06:39:03 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > On Nov 8, 9:38am, Peter Stephenson wrote: > } > } I think the problem with making this silent is it's not currently > } trivial to check that the builtin that's there is actually the same as > } the one you're trying to add, so in theory it's not safe to ignore > > If you want to ignore it, "zmodload -ia zsh/stat zstat" works. I don't > think there's any reason to make -i obsolete in this case. Hmmm... the reason is we're getting reports for things that probably aren't actually bugs, and I for one would rather only get reports for actual errors. We removed the need -i from the case of "zmodload zsh/stat" because it's not an error if zsh/stat gets loaded when zsh/stat is already present. It seems to me it's equally not an error to mark zstat as a builtin from zsh/stat if it's already loaded as a builtin from zsh/stat. It would only be an error if there's a conflict. That's how "autoload" works, after all: it can't check for a conflict (without major faff) but it does check if a function's already loaded. pws ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-08 16:11 ` Peter Stephenson @ 2013-11-09 2:11 ` Bart Schaefer 2013-11-09 3:35 ` John 2013-11-09 22:32 ` Peter Stephenson 0 siblings, 2 replies; 16+ messages in thread From: Bart Schaefer @ 2013-11-09 2:11 UTC (permalink / raw) To: Peter Stephenson, zsh-users On Nov 8, 4:11pm, Peter Stephenson wrote: } } It seems to me it's equally not an error to mark zstat as a builtin from } zsh/stat if it's already loaded as a builtin from zsh/stat. It would } only be an error if there's a conflict. } } That's how "autoload" works, after all: it can't check for a conflict } (without major faff) but it does check if a function's already loaded. I'm confused; these statements seem contradictory, so I must be missing something. If we can't check for a conflict, how can we suppress the error message? I.e., how do we know that zstat is already loaded as a builtin from the same module we're now loading? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-09 2:11 ` Bart Schaefer @ 2013-11-09 3:35 ` John 2013-11-09 5:20 ` Shawn Wilson 2013-11-09 22:32 ` Peter Stephenson 1 sibling, 1 reply; 16+ messages in thread From: John @ 2013-11-09 3:35 UTC (permalink / raw) To: zsh-users On 11/8/13, 7:11 PM, Bart Schaefer wrote: > On Nov 8, 4:11pm, Peter Stephenson wrote: > } > } It seems to me it's equally not an error to mark zstat as a builtin from > } zsh/stat if it's already loaded as a builtin from zsh/stat. It would > } only be an error if there's a conflict. > } > } That's how "autoload" works, after all: it can't check for a conflict > } (without major faff) but it does check if a function's already loaded. > > > I'm confused; these statements seem contradictory, so I must be missing > something. If we can't check for a conflict, how can we suppress the > error message? I.e., how do we know that zstat is already loaded as a > builtin from the same module we're now loading? Could you do something as simple as remember a checksum (or md5sum) and maybe the filename when it's loaded? It seems like that would catch everything with a low risk of false matches. John ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-09 3:35 ` John @ 2013-11-09 5:20 ` Shawn Wilson 0 siblings, 0 replies; 16+ messages in thread From: Shawn Wilson @ 2013-11-09 5:20 UTC (permalink / raw) To: John, zsh-users John <jmharres@gmail.com> wrote: >On 11/8/13, 7:11 PM, Bart Schaefer wrote: >> On Nov 8, 4:11pm, Peter Stephenson wrote: >> } >> } It seems to me it's equally not an error to mark zstat as a builtin >from >> } zsh/stat if it's already loaded as a builtin from zsh/stat. It >would >> } only be an error if there's a conflict. >> } >> } That's how "autoload" works, after all: it can't check for a >conflict >> } (without major faff) but it does check if a function's already >loaded. >> >> >> I'm confused; these statements seem contradictory, so I must be >missing >> something. If we can't check for a conflict, how can we suppress the >> error message? I.e., how do we know that zstat is already loaded as >a >> builtin from the same module we're now loading? >Could you do something as simple as remember a checksum (or md5sum) and > >maybe the filename when it's loaded? It seems like that would catch >everything with a low risk of false matches. > I think that's overkill. I think giving a return status of 2 or 255 might be sufficient. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.0.2-test-1 is available 2013-11-09 2:11 ` Bart Schaefer 2013-11-09 3:35 ` John @ 2013-11-09 22:32 ` Peter Stephenson 1 sibling, 0 replies; 16+ messages in thread From: Peter Stephenson @ 2013-11-09 22:32 UTC (permalink / raw) To: Zsh Users On Fri, 08 Nov 2013 18:11:43 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > On Nov 8, 4:11pm, Peter Stephenson wrote: > } > } It seems to me it's equally not an error to mark zstat as a builtin from > } zsh/stat if it's already loaded as a builtin from zsh/stat. It would > } only be an error if there's a conflict. > } > } That's how "autoload" works, after all: it can't check for a conflict > } (without major faff) but it does check if a function's already loaded. > > > I'm confused; these statements seem contradictory, so I must be missing > something. If we can't check for a conflict, how can we suppress the > error message? I.e., how do we know that zstat is already loaded as a > builtin from the same module we're now loading? For functions, autoload (the builtin of that name) works this way, suppressing an error message if a functiona already exists, but it can't check for a conflict because it would have to scan the path, load the file it found, and check that the loaded file compared the same as the already loaded file. This is as much work as deleting the file and reloading it when "autoload" is encountered again. So it silently assumes if a function is loaded that it's the function you wanted. I was using this case as the paradigm of how an autoload of any sort works, to point out that, when whatever-it-is is already loaded, generating an error on a new autoload isn't necessarily the right thing to do. For autoloads from modules, which may be builtins, conditions, math functions or parameters, we can actually do a bit better, with a little more work but nothing like to the same extent (no additional loading is required). Suppose we load builtin bar from zsh/foo at some point, doesn't matter how, then run "zmodload -a bar zsh/foo". We find that a builtin bar exists. We can then check that zsh/foo is already loaded, and is already providing builtin bar. It seems to me, based on the argument from functions, that it would be entirely natural just to ignore the zmodload -a as redundant rather than report it as an error; and, furthermore, given that you can check by this means the effect really *is* redundant rather than a conflict, it seems to me there is no harmful side effect of any sort. (Obviously, contradictory indications are invited.) I hope that's clear now. I started looking at this on Friday but I need to be careful which builtins flying around are which, so will get back to it at some point. pws ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-11-09 22:33 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-06 20:23 zsh 5.0.2-test-1 is available Peter Stephenson 2013-11-06 21:57 ` Phil Pennock 2013-11-07 15:33 ` Axel Beckert 2013-11-07 16:05 ` Peter Stephenson 2013-11-07 19:18 ` Phil Pennock 2013-11-08 1:36 ` Bart Schaefer 2013-11-08 3:16 ` Axel Beckert 2013-11-08 6:01 ` Bart Schaefer 2013-11-08 7:16 ` Phil Pennock 2013-11-08 9:38 ` Peter Stephenson 2013-11-08 14:39 ` Bart Schaefer 2013-11-08 16:11 ` Peter Stephenson 2013-11-09 2:11 ` Bart Schaefer 2013-11-09 3:35 ` John 2013-11-09 5:20 ` Shawn Wilson 2013-11-09 22:32 ` Peter Stephenson
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).