From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19937 invoked from network); 3 May 2007 15:46:39 -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; 3 May 2007 15:46:39 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 1217 invoked from network); 3 May 2007 15:46:34 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 3 May 2007 15:46:34 -0000 Received: (qmail 6582 invoked by alias); 3 May 2007 15:46:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23389 Received: (qmail 6573 invoked from network); 3 May 2007 15:46:30 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 3 May 2007 15:46:30 -0000 Received: (qmail 912 invoked from network); 3 May 2007 15:46:30 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 3 May 2007 15:46:27 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly24c.srv.mailcontrol.com (MailControl) with ESMTP id l43Fi20F014558 for ; Thu, 3 May 2007 16:46:19 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 16:46:14 +0100 Date: Thu, 3 May 2007 16:46:14 +0100 From: Peter Stephenson To: zsh-workers@sunsite.dk Subject: Re: [PATCH] Proposal: stat -> zstat Message-Id: <20070503164614.497b44d1.pws@csr.com> In-Reply-To: <070503074822.ZM24666@torch.brasslantern.com> References: <20070503053952.GA1481@redoubt.spodhuis.org> <070503074822.ZM24666@torch.brasslantern.com> Organization: Cambridge Silicon Radio X-Mailer: Sylpheed version 2.2.10 (GTK+ 2.10.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2007 15:46:14.0125 (UTC) FILETIME=[2E1979D0:01C78D9A] X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.67.0.134 Bart Schaefer wrote: > Perhaps what we should be thinking of is a more general utility for > zmodload, along the lines of Perl's export-tag semantics, so that a > module can be asked to selectively install only those bits that the > caller needs. How about the following. This tries quite hard not to break anything. Each module can advertise a set of features it supports. These will be variables, builtins, conditions or math functions; we'll need a convention for how to disambiguate. I wouldn't propose to build the convention into the API, however, just represent each feature by a string and rely on modules to use the convention. This makes it extensible. At the C API, we can then add standard module functions to query and enable or disable features. On most systems we can just search for appropriate functions; on AIX there's some magic I don't yet understand turning the standard module functions into an index, so it might be harder. Since we need to recompile modules for each version of the shell, this only becomes a problem with someone else's add-on that hasn't been upgraded. We can have one function to pass up a string list of features as an array and the current set of enabled features, and another function to pass down the new set of enabled features. The default is for all features to be enabled. The list of features is in the same internal format as a zsh array. The set of enabled features can be an arbitrary-length array of unsigned integers with bits giving the enabled status. We can explicitly limit ourselves to the first 32 bits of each integer for future proofing. Obviously we need one bit for each feature array element. Alternatively, we could use an integer array of the same length as the feature list and declare all but the bottom bits a being for future expansion. At the shell command API, zmodload loads everything (as at present). If the module is already loaded, and supports features, zmodload will check to see if all features are loaded. If they are, it's an error. If not, it will enable them all. (This is necessary to fix cases like a function looking for a builtin it knows is supplied by a module and loading the module if it doesn't find the builtin.) zmodload -i will load the module if it's not loaded, and enable all features. zmodload -F feature1 feature2 will load the module or cause an error if it's already loaded, and turn on feature1 and feature2 (only---all others are disabled). zmodload -iF -feature1 feature3 will load the module if it's not already loaded, turn off feature1 and turn on feature3, leaving all other features alone. zmodload -lF lists all enabled features of , one per line. It returns status 1 (printing an error message? or not?) if is not loaded. zmodload -LF lists the zmodload commands required to turn on the currently enabled set of features. This might be "zmodload " if all features are enabled. If you try to enable or disable a feature the module doesn't say it supports, an error message is printed and status 1 is returned (but any other feature change requests will be processed). New functions that just require particular features will call "zmodload -iF features...". Older functions can still call "zmodload -i" and rely on all the feature being present. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview