From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1002 invoked by alias); 19 Jun 2015 20:21:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35536 Received: (qmail 25029 invoked from network); 19 Jun 2015 20:21:52 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.0 X-Originating-IP: [80.3.228.158] X-Spam: 0 X-Authority: v=2.1 cv=RLtOZNW+ c=1 sm=1 tr=0 a=P+FLVI8RzFchTbbqTxIDRw==:117 a=P+FLVI8RzFchTbbqTxIDRw==:17 a=kj9zAlcOel0A:10 a=NLZqzBF-AAAA:8 a=q2GGsy2AAAAA:8 a=qkKzcuWYqaCIK2bSRSYA:9 a=CjuIK1q_8ugA:10 Date: Fri, 19 Jun 2015 21:16:16 +0100 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: Typeset with array Message-ID: <20150619211616.5232274c@ntlworld.com> In-Reply-To: <150619115454.ZM4290@torch.brasslantern.com> References: <5578996E.3080700@thequod.de> <150610191427.ZM30841@torch.brasslantern.com> <5579C247.1060800@thequod.de> <150611183639.ZM32247@torch.brasslantern.com> <20150612094237.338f79d5@pwslap01u.europe.root.pri> <20150619123930.2688d9e3@pwslap01u.europe.root.pri> <20150619150624.3368cd00@pwslap01u.europe.root.pri> <150619115454.ZM4290@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 19 Jun 2015 11:54:54 -0700 Bart Schaefer wrote: > Does this raise a larger question of whether the reserved word should be > enabled by default in "zsh mode"? Yes, indeed. > If this only affects the reserved word interface and the reserved word > has to be explicitly enabled (by "emulate" or "enable") then there's no > issue. > > OTOH it would be nice to have the reserved word on by default. Using > array assignment syntax in the arguments of typeset would generally have > been a syntax or globbing error in the past, so this word splitting is > the primary place where a valid statement might change its semantics. Right. I'm assuming the ability to do local scalar=stuff array=(more stuff) is so obviously natural we should find some way of enabling it by default unless we hit some insuperable objection. > } kludge in the old behaviour with NO_KSH_TYPESET if it seems desirable, > > Are there any other practical differences between KSH_TYPESET and having > the reserved word enabled? Effectively, KSH_TYPESET was just a partial fix-up for the reserved word behaviour, missing array handling, Actually, more than that, in bash at least (I wouldn't be surprised if ksh was similar), $ declare=declare $ $declare foo=`echo bar one=two` $ echo $one two which is NO_KSH_TYPESET behavioru --- so logically KSH_TYPESET should be *off* from now on, but the reserved word scheme on, in emulation mode, whatever happens in native mode. > } though logically that shouldn't really control the reserved word > } interface which should parse consistently. > > Agreed. I think there are two arguments around NO_KSH_TYPESET behaviour in native mode (however arrived at): 1. We've always done it that way so should continue. 2. The only reason we left it that way by default is the fact that KSH_TYPESET was only ever a partial fix that didn't parse assignments properly. With that objection removed there's no real reason for NO_KSH_TYPESET; and further anyone relying on typeset foo=`echo one=two` doing what it now does needs to get out more as it's an accident waiting to happen. I'm inclining to 2, but that may be because (as with the case parsing change) I'm mssing some more widespread effect. I'd vaguely guess that anyone that didn't read the manual in some detail wouldn't be aware of the current state of affairs. The various other questions noted by you and Oliver are less fraught. pws