From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28348 invoked by alias); 10 Jan 2015 20:28:59 -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: 34221 Received: (qmail 18854 invoked from network); 10 Jan 2015 20:28:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=umjCIRLRIS4PQpxnbae+4/QFdSz3TwWiLjXTFMg4V18=; b=zfSVuu2rumCOd0YvmkQzvtmrZRNFrueSECEmAaaSLMbh9QK5mzZw0U0cUsI0HfPa2L Mwwygymi6DewqlI3vBmFVKl+Z/CZSpLmpcHe7272NN0nXOVr1kfuHICxq+3qCvCP4wqK +875Md1/dlLBIO/U79eA7ecieFC7ouaNIMmnzu8NtiPBKRa/2F5OFrZ8D7KEedH5UMpJ X2Om3txhLnYRTp2wvoLr3gqp4f1ZrAkZYnrAO7nuoaVZwCQHWxj5PYhB/3DqXgMp92sA E86/qGtVm+diZoO/PxfjV7I5u05RuYGpExmcJ/MCz7L53CL4oztYNhDvvLW+9xp4gEy3 snkg== MIME-Version: 1.0 X-Received: by 10.107.130.197 with SMTP id m66mr21359113ioi.10.1420921734854; Sat, 10 Jan 2015 12:28:54 -0800 (PST) In-Reply-To: <150110120412.ZM21448@torch.brasslantern.com> References: <150109225231.ZM24510@torch.brasslantern.com> <150110092530.ZM28263@torch.brasslantern.com> <150110102827.ZM28394@torch.brasslantern.com> <150110120412.ZM21448@torch.brasslantern.com> Date: Sat, 10 Jan 2015 21:28:54 +0100 Message-ID: Subject: Re: Crash when exporting scalar without value and getsparam fails From: Mikael Magnusson To: Bart Schaefer Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On Sat, Jan 10, 2015 at 9:04 PM, Bart Schaefer wrote: > On Jan 10, 8:10pm, Mikael Magnusson wrote: > } > } % unset IFS > } % export IFS > } % IFS=5 > } % unset IFS > } % printenv|grep IFS # this would be empty for a normal parameter > } IFS=5 > > OK, so the remaining issue is that the PM_EXPORT flag is not cleared > when a special parameter is unset. > > I think this is within the definition of how a special paramter behaves; > i.e., it retains all its attributes even when unset. In this case we > have an attribute that's not normally "part of the specialness" of the > parameter, which is also being preserved. The same thing happens with > other flags on other specials, e.g.: > > torch% print $SECONDS > 762 > torch% typeset -E SECONDS > torch% print $SECONDS > 7.801753190e+02 > torch% unset SECONDS > torch% print $SECONDS > > torch% SECONDS=763 > torch% print $SECONDS > 7.671235090e+02 > > > So should e.g. stdunsetfn() and tiedarrunsetfn() clear the PM_EXPORTED > flag as well as assert the PM_UNSET flag? Or is that going to cause a > problem elsewhere because there is a special parameter that has the > feature of always being exported? I can't think of any, but maybe we > shouldn't rule it out ... in which case this gets really hairy, as we > will have to know, for every special, what flags should or should not > be retained across unset. Ah, these are good points. I don't have any especially strong feelings about making IFS stop being exported after unset, I was just reporting what I observed in case it indicated some further wonkiness. -- Mikael Magnusson