From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16415 invoked by alias); 10 Feb 2014 20:25:00 -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: 32375 Received: (qmail 24434 invoked from network); 10 Feb 2014 20:24: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.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1WmhUf9KmH7M46V1xzheYDjUdmftuZA3JdTiKqpawKw=; b=klnEGLF0pqIShUTIt2i/IW2zocJHzWn78sZXyTs210re0zSvPiQS59+3Ckk7SzC7Hu d4gyU21aEzqVgtI9kM69YOPMWfoz9skn1kr+Vj+Kal50P70Tt37ngvGFyjYmFruShQdP HeXp+j6y/JvnP0FZmGL8NOREvnZmPL6dp8/6m2NBexCoY2eROYONz3WTUmazGBueaRoD f7FXlRz7fyPxo5FCTUKqag6UgLIMZ9kvSp4Lh2P6RWyKK8dKslaczEO3MjUUQy54dVL8 lGB4cxuxAeCxdt9s86L0h2gWUyUiqHVpzFE+8EVpk8Dd4eYhw3ylqOlnNTvLPaotDuU9 7+Mg== X-Gm-Message-State: ALoCoQnSqCunBtf78nyL/ehoTKPljBUsKM3Gxcl6J/IqYQlhSxpYKaJk4bAH6Gl8d1sAg+shwRvp MIME-Version: 1.0 X-Received: by 10.152.9.65 with SMTP id x1mr23554149laa.6.1392063891396; Mon, 10 Feb 2014 12:24:51 -0800 (PST) In-Reply-To: <87vbwn9ch5.fsf@ft.bewatermyfriend.org> References: <87vbwn9ch5.fsf@ft.bewatermyfriend.org> Date: Mon, 10 Feb 2014 12:24:51 -0800 Message-ID: Subject: Re: Unset special parameters From: Bart Schaefer To: Zsh hackers list Content-Type: multipart/alternative; boundary=089e0158b8eac0695504f2132160 --089e0158b8eac0695504f2132160 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 8:08 AM, Frank Terbeck wrote: > Hi list, > > Since commit f3e7cfe47c32a23, some special parameters are initialised to > be unset. Among them PS1 and RPS1. Which means that prompt-themes need > to mark these parameters as global, because otherwise shells running > with 'warn_create_global' set will complain. > Hrm, I never remember about that option. Definitely an unforeseen side-effect, and possibly a reason to back out some of those changes. Compare my mention of breakage if e.g. OPTIND is declared unset. > prompt_ft_precmd () { > # ... > typeset -g RPS1 > RPS1='foo' > # ... > } > > ...which still triggers the warning. Hmm. Consider this: dfn_xyz() { typeset -g XYZ; unset XYZ; XYZ=foo } dfn_xyz prints the warning, because "typeset -g XYZ" has only caused XYZ to "exist" until the point at which it is unset again. Is this also a bug? If instead I do dfnset_xyz() { typeset -g XYZ=123; unset XYZ; XYZ=foo } dfnset_xyz does NOT give the warning, because assigning in typeset has caused the variable to become a "real" global which survives the unset. An analogous thing is going on here with RPS1. It already exists but in an unset state; typeset -g without an assignment doesn't cause it to reappear, so you get the warning when assigning to it. (On the other hand "typeset -g" of a nonspecial DOES cause it to reappear, that's one of the differences in the handling of a special.) Probably this means startparamscope() has to do something differently with specials that have PM_UNSET. --089e0158b8eac0695504f2132160--