From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21578 invoked by alias); 29 Apr 2015 11:01:26 -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: 34994 Received: (qmail 20871 invoked from network); 29 Apr 2015 11:01:14 -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=lunL8nml/73Z4vxyhe9FCUC+E22hkAe7MhffhTAdBqM=; b=e5zGkabP7buYsgLVKvT6PyoQ3zClh+z3d9SGg3tLltHGHWnJUOt7KR+cKA1pbb1Prx nhlk+iB5ez7flGoUoIq9r4vmXyvBBKrc6XRFa3aboyDnwp7sQzR9cW02Gs/bf1NZNFNj gEXKiECcZSyrjPVCM44ENLMZXEIjCgnEf8DlQRDZ5AREiiuXgUU40S6Y7unD4bxKOMN1 Xbob8BEWs5Vqt2FhCvuEqYdNBtB09kn/c1f3c3rHsE2ksslURr1Xb7Qk6nyHg/U4kSXV gsq0WLBg/RqCgiOIIYVwbOJzpFd7d1J3iZb/onrObcGccbbo4ffavyTQBH9P+r7b2DM5 EXPg== MIME-Version: 1.0 X-Received: by 10.50.114.35 with SMTP id jd3mr26699292igb.14.1430305270564; Wed, 29 Apr 2015 04:01:10 -0700 (PDT) In-Reply-To: References: <55407BBF.6020401@inlv.org> <20150429113602.374240c7@pwslap01u.europe.root.pri> Date: Wed, 29 Apr 2015 13:01:10 +0200 Message-ID: Subject: Re: [BUG] Can't mark unset variables as read-only From: Mikael Magnusson To: Peter Stephenson Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On Wed, Apr 29, 2015 at 12:57 PM, Mikael Magnusson wrote: > On Wed, Apr 29, 2015 at 12:36 PM, Peter Stephenson > wrote: >> On Wed, 29 Apr 2015 08:35:43 +0200 >> Martijn Dekker wrote: >>> Unlike other shells, zsh can't mark an unset variable as read-only. >> >> Yes, the standard does indeed require that ability. As you can imagine, >> something like this that completely breaks the normal programming model >> of variables (a variable can't have state if it's unset because it >> doesn't exist) is a nightmare to implement; however, it can at least be >> limited to the POSIXBUILTINS option and maybe the cases using that are >> simple enough that it mostly works. I'm sure there are any number of >> strange edge cases, though. >> >> The output of "readonly -p" is still broken (doesn't show the unset >> variables in a fashion that can be used for restoring the current state) >> but it was anyway: >> >> typeset -ar '*' >> *=() >> >> Er, no, I don't think that's going to work. >> >> So that can be fixed separately. > > I wanted the opposite thing the other day, sort of. I have a ZLE > widget that looks at $WIDGET, and I wanted to reuse it by calling it > from another widget, setting WIDGET to another value first. However, > ZLE makes $WIDGET readonly special, and I couldn't find any > combination of flags that let me make a non-readonly local WIDGET. Is > that possible? > > % zle -N h; h() { local -h WIDGET; WIDGET=hi; echo $WIDGET }; bindkey '^[h' h > % > h: read-only variable: WIDGET > % zle -N h; h() { local +r -h WIDGET; WIDGET=hi; echo $WIDGET }; bindkey '^[h' h > % > h:local: WIDGET: can't change type of a special parameter > % zle -N h; h() { local WIDGET; WIDGET=hi; echo $WIDGET }; bindkey '^[h' h > % WIDGET=h > > h: read-only variable: WIDGET > > compared to > % () { readonly foo=3; () { local foo=5; echo $foo }; echo $foo } > 5 > 3 Even when you think about something for a couple of days, you don't realize what the answer is until after you send the question to a public forum. ZLE makes the scope of the WIDGET parameter start inside the widget function already (which is confusing), so it is already local. The answer is to start another parameter scope first, % zle -N h; h() { () { local -h WIDGET; WIDGET=hi; echo $WIDGET } }; bindkey '^[h' h % hi -- Mikael Magnusson