From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-18125-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 10895 invoked by alias); 8 Nov 2013 09:38:33 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 18125
Received: (qmail 19884 invoked from network); 8 Nov 2013 09:38:28 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-AuditID: cbfec7f4-b7fee6d000004b2d-d2-527cb10f8a11
Date: Fri, 08 Nov 2013 09:38:22 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>, zsh-users@zsh.org
Subject: Re: zsh 5.0.2-test-1 is available
Message-id: <20131108093822.1534aa88@pwslap01u.europe.root.pri>
In-reply-to: <20131108071627.GA6216@redoubt.spodhuis.org>
References: <20131106202321.4a48c77b@pws-pc.ntlworld.com>
 <20131107153315.GW3544@sym.noone.org>
 <20131107160551.7aa195dc@pwslap01u.europe.root.pri>
 <20131107191806.GA85153@redoubt.spodhuis.org>
 <131107173627.ZM24325@torch.brasslantern.com>
 <20131108071627.GA6216@redoubt.spodhuis.org>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsVy+t/xq7r8G2uCDE6tsrbYcXIlo8WRaxfZ
	HJg8rrY9ZvNYdfADUwBTFJdNSmpOZllqkb5dAlfG087XrAUX2Cu2v+1lbGCczNbFyMkhIWAi
	cfb8BFYIW0ziwr31QHEuDiGBpYwS8//fY4Jw+pkk7m24yQxSxSKgKjH5zgWwDjYBQ4mpm2Yz
	djFycIgIeEu0XE0ECQsLaEn8P34VrIRXwF7ixpuXLCA2p4ClRO/CBkaImcuYJD5eX84OkuAX
	0Je4+vcTE8QV9hIzr5xhhGgWlPgx+R5YMzPQ0M3bmlghbHmJzWveMk9gFJiFpGwWkrJZSMoW
	MDKvYhRNLU0uKE5KzzXUK07MLS7NS9dLzs/dxAgJzC87GBcfszrEKMDBqMTDW3ChOkiINbGs
	uDL3EKMEB7OSCO/upTVBQrwpiZVVqUX58UWlOanFhxiZODilGhgL5sgwGbyuf7iuS5f/ydTV
	0zxefGicfqXFKubU1k9TZ+4y7f4SpH83617K79ZbYrV2inxb1pt0r42OWKepJ6ZxT13uXOV0
	T8WZjCVzGbkefGFfOnNvxakXO7eEbn6b3TrxHc+8nFllrApXr/HuPD8vudX5wnOZ/d/2nzxd
	+YKrSiC9X/qSmlKrEktxRqKhFnNRcSIAWFuYEyoCAAA=

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