From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29517 invoked from network); 6 May 2007 01:08:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 May 2007 01:08:16 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 98237 invoked from network); 6 May 2007 01:08:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 May 2007 01:08:10 -0000 Received: (qmail 17912 invoked by alias); 6 May 2007 01:07:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23392 Received: (qmail 17901 invoked from network); 6 May 2007 01:07:56 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 6 May 2007 01:07:56 -0000 Received: (qmail 97905 invoked from network); 6 May 2007 01:07:56 -0000 Received: from redoubt.spodhuis.org (HELO mx.spodhuis.org) (193.202.115.177) by a.mx.sunsite.dk with SMTP; 6 May 2007 01:07:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=first1; d=spodhuis.org; h=Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=BflSqk7J7CjjQsKDXq4/FiOEFwASb8WyT2XBffQcyp0iuSqB9Af85lRfPe3AANb6pxbv4V++jawYbL/WZXgmLcqoWSCp6Zcf34+86PZnKdMMwlrFErMwJOn29NjpbFsvsLnlGoT07aVIil9ICh1l1TbNV3MWA49LkseMwdVeCsA=; Received: by smtp.spodhuis.org with local id 1HkVE6-000CFP-Sz; Sun, 06 May 2007 01:07:50 +0000 Date: Sat, 5 May 2007 18:07:50 -0700 From: Phil Pennock To: zsh-workers@sunsite.dk Subject: Re: [PATCH] Proposal: stat -> zstat Message-ID: <20070506010750.GA46162@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@sunsite.dk References: <20070503053952.GA1481@redoubt.spodhuis.org> <20070503095025.38ceb321.pws@csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070503095025.38ceb321.pws@csr.com> On 2007-05-03 at 09:50 +0100, Peter Stephenson wrote: > Adding zstat is useful. We could possibly still make modules that only > use it internally disable stat if the module wasn't previously > loaded---otherwise removing the disabling actually makes things worse. Hrm. Situation before: If zsh/stat loaded and stat enabled: happy days If zsh/stat loaded and stat disabled: temporarily reenable, disable with exception If zsh/stat not loaded and user likes builtin stat: gloriously happy days If zsh/stat not loaded and user dislikes builtin stat: manual-page documents work-around Situation with my patch: If zsh/stat loaded and zstat enabled: happy days, don't touch stat If zsh/stat loaded and zstat disabled: hrm. Why would zstat be disabled? Perhaps worth covering, but nothing else works around "functions loaded but disabled" so this would be the exception If zsh/stat loaded and stat disabled: Fine. We leave it that way. If zsh/stat not loaded and user likes builtin stat: gloriously happy days If zsh/stat not loaded and user dislikes builtin stat: manual-page documents work-around (same) I'm not seeing what makes things worse. History suggests that given that you've claimed it does then I'm wrong and just not seeing it, so I'd appreciate a clarification. :^) Now, one thing which might be useful in addition to the proposed extended syntax for zmodload would be to add a new flag BINF_DISABLED which actually names the (1<<0) case and offers something to go in a module, so that a builtin table entry can per definition be disabled by default. So the stat documentation note could state something like: In the next major release of zsh, stat will still be a valid loadable command but it will not be enabled by default. If you need to maintain a script's compatibility across different versions of zsh, then a good idea is to _now_ add an explicit "enable stat" after "zmodload zsh/stat". In this and older releases of zsh, the explicit enable is harmless. In the next major version, it will allow the script to work unmodified. If you only need compatibility with version 3.1.6 or newer, then you can move to zstat now and avoid introducing stat unnecessarily when the zsh is recent enough by using this code: zmodload -i zsh/parameter zsh/stat if [[ $builtins[stat] == defined && $builtins[zstat] != defined ]] then function zstat { builtin stat "$@" } fi As an aside: I explicitly check against 'defined' instead of non-zero since this is more resilient to *cough* people who put: zmodload -ab -i zsh/stat stat zstat in a startup file unguarded by version numbers as it's "harmless". *whistles innocently* With documentation like this, and a phased approach to any change, I think that it'd be fair to say that zsh still takes backwards compatibility somewhat more seriously than some other shells I could name. I'm not sure how to word "next major release" to cleanly convey "the stable release directly after, not counting patch-levels, the stable release in which this was introduced (and if you're using zsh 4.3.x then note that this is unstable, so we're giving you more time)". The only way would be to commit to explicit release version numbers. zsh 4.4 adds zstat, 4.6 disables stat by default, 4.8 removes stat? Or does anyone have thoughts about a zsh 5? Personally, I think that multibyte support is significant enough to warrant 5.0 following 4.3.x. At times after the EU added the Euro and I switched to UTF-8, I found missing multibyte support a reason to do some things in other shells. (Why use a rarely found Latin 9 when you can bite the bullet and switch to something more global?) -Phil