From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26254 invoked from network); 20 Dec 2004 11:52:26 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 20 Dec 2004 11:52:26 -0000 Received: (qmail 66428 invoked from network); 20 Dec 2004 11:52:20 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 20 Dec 2004 11:52:20 -0000 Received: (qmail 13239 invoked by alias); 20 Dec 2004 11:52:07 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8304 Received: (qmail 13225 invoked from network); 20 Dec 2004 11:52:06 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 20 Dec 2004 11:52:06 -0000 Received: (qmail 64651 invoked from network); 20 Dec 2004 11:51:06 -0000 Received: from mailhost1.csr.com (HELO MAILSWEEPER01.csr.com) (81.105.217.43) by a.mx.sunsite.dk with SMTP; 20 Dec 2004 11:51:05 -0000 Received: from exchange03.csr.com (unverified [10.100.137.60]) by MAILSWEEPER01.csr.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 20 Dec 2004 11:49:47 +0000 Received: from news01.csr.com ([10.103.143.38]) by exchange03.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Dec 2004 11:52:18 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.1/8.12.11) with ESMTP id iBKBp2bl018735 for ; Mon, 20 Dec 2004 11:51:02 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.13.1/8.13.1/Submit) with ESMTP id iBKBp14U018627 for ; Mon, 20 Dec 2004 11:51:02 GMT Message-Id: <200412201151.iBKBp14U018627@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-users@sunsite.dk Subject: Re: local/typeset stupidity In-reply-to: <20041220112025.GA9720@puritan.pcp.ath.cx> References: <20041220112025.GA9720@puritan.pcp.ath.cx> Date: Mon, 20 Dec 2004 11:51:00 +0000 From: Peter Stephenson X-OriginalArrivalTime: 20 Dec 2004 11:52:18.0604 (UTC) FILETIME=[5B5EEEC0:01C4E68A] X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 Nikolai Weibull wrote: > Why the doesn't local work like one would expect? If i > write > > func () { > local s="..." > } > > then I don't expect zsh to respond with > > func:local:1: not valid in this context: 100 > > right? There's something you're not telling us. With the default zsh options the syntax you show is guaranteed to work. My guess is something is causing what you show in "..." to be split into words. Is there a "$@" inside it? For example, func() { local s="$@" } func foo 100 would produce an error like the one you show, because the line is effectively split up as local s="foo" 100 To assign all the arguments to s without splitting you would need s="$*". > local s; s="..." > > works fine, though, even with typesetsilent off. s="..." is special syntax; it's recognised as a scalar assignment, so wordsplitting is implicitly turned off. This differs from "local" which has the semantics of a normal builtin, almost (actually, there's special behaviour of ~'s and ='s at the start of the value). This is rather nasty. People often expect assignments after "local" etc. to be the same as assignments on their own, but that syntax conflicts with the way the arguments of builtins, and any other commands, are handled. There's no simple answer, but retaining builtin syntax is at least predictable and stops the already horrendous code for local variables from becoming any worse. Any way round is a kludge of some sort. > Even with > > setopt typesetsilent # (how can't this be the default?) typesetsilent works around a different problem: func() { local s; local s; } func outputs s='' unless the option is turned on. This came from the very early days of zsh. It was mostly useful for examining the state of variables that already exist interactively; it's not obvious you would use it in a function. It's annoying this is the default behaviour. There may be a better way of suppressing the output in functions, but I'm not sure whose functions it would break. Personally I'd be quite happy to have the effect of typesetsilent enforced inside functions. A compromise would be to keep the non-silent behaviour only for "typeset" itself. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************