From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9570 invoked from network); 14 Jan 2009 17:22:55 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Jan 2009 17:22:55 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 12462 invoked from network); 14 Jan 2009 17:22:50 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Jan 2009 17:22:50 -0000 Received: (qmail 7943 invoked by alias); 14 Jan 2009 17:22:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26308 Received: (qmail 7931 invoked from network); 14 Jan 2009 17:22:45 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Jan 2009 17:22:45 -0000 Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id F214580271F0 for ; Wed, 14 Jan 2009 18:22:42 +0100 (CET) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly02d.srv.mailcontrol.com (MailControl) with ESMTP id n0EHMfd5011001 for ; Wed, 14 Jan 2009 17:22:41 GMT Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 17:22:41 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id n0EHMZTC002948 for ; Wed, 14 Jan 2009 17:22:36 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id n0EHMZwf002944 for ; Wed, 14 Jan 2009 17:22:35 GMT Message-Id: <200901141722.n0EHMZwf002944@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: Getting the CVS revision of Zsh In-reply-to: <090114085737.ZM18662@torch.brasslantern.com> References: <2d460de70901090301h6b309a7cm19c5ebfec989ff2c@mail.gmail.com> <2d460de70901140533icf13f94yc7f63f974b236f45@mail.gmail.com> <090114085737.ZM18662@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Wed, 14 Jan 2009 08:57:37 -0800." Date: Wed, 14 Jan 2009 17:22:35 +0000 From: Peter Stephenson X-OriginalArrivalTime: 14 Jan 2009 17:22:41.0117 (UTC) FILETIME=[B45AE0D0:01C9766C] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.68.0.112 X-Virus-Scanned: ClamAV 0.92.1/8864/Wed Jan 14 13:50:32 2009 on bifrost X-Virus-Status: Clean (I've moved this to zsh-workers, there doesn't seem to be anything left of use to general users.) Bart Schaefer wrote: > If you're a packager like Debian or RedHat who occasionally ports > individual patches backwards or sideways or makes your own stability > patches, anything in these variables is going to be either wrong and > misleading to the end user or fabricated and meaningless to the zsh > developers upstream. If that was what was going on, I would agree, but I did this on the understanding that someone, for what ever reasons, might ship an intermediate CVS checkout substantially unchanged as a development package. In fact, I thought this was basically what Debian did. ("Ship" might also mean "install for local users because they need a bug fix or new feature before the release", or something of that kind.) Then $ZSH_PATCHLEVEL tells you where it came from and what you can do with it. It gives the developers more information, too, if some packaged is tracking CVS, without the package maintainers getting involved. It's worse than making a proper release, but better than not having any idea about the provenance of the shell. If someone is really bundling individual patches with zsh, so that it is different from any CVS checkout, then I would urge them to alter $ZSH_PATCHLEVEL to avoid exactly the sort of confusion you describe. I can add a config option to fix a patchlevel if this is useful. > I was holding my tongue on ZSH_PATCHLEVEL despite my annoyance that > it uses the RCS $Revision: tag -- I mirror the zsh sources into my > own local repository, which means that tag gets rewritten whenever > I do a check-in, so my local build will rarely if ever match the > "real thing", hence it's useless cruft to me Surely you can turn keyword expansion off on that file, if you want? However, if you're never going to use it anyway then it *is* useless cruft to you, of course. By this definition a large part of the shell is useless cruft to me, too. Actually, I suspect I *will* use this myself occasionally. It answers those occasional development questions "did I install the version with that bug fix, or did I just compile it, or am I dreaming again?" No, this is not a typical user case but for a few dozen bytes it's worth it. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070