From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1042 invoked by alias); 30 Jun 2012 05:05:29 -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: 30550 Received: (qmail 28065 invoked from network); 30 Jun 2012 05:05:18 -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=-3.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, DKIM_SIGNED,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at spodhuis.org does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201107; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=FB6gMVxsUyciJORYupvXxBACXO9IUVdDzgpgq/psfCI=; b=g9dkCpyB93VTnHq12cxz+W1dBGlIkBKCoxR9VFC2k/oOoeAgl88vWuCuTK+7rcAzOXISUY4jmfIouGU9IkMJ9tZ4SLXpYj8IPIn8WSIRJfJngAyqMh3Fg7EDM6jvk8rJ0WhpyRdVtzOA/lQ6KZicfU8HRH5lJTjgAa9MbVvuXHk=; Date: Fri, 29 Jun 2012 22:05:12 -0700 From: Phil Pennock To: Peter Stephenson Cc: zsh-workers@zsh.org Subject: Re: 4.3.17 unset RPS1 vs RPROMPT Message-ID: <20120630050512.GA87092@redoubt.spodhuis.org> Mail-Followup-To: Peter Stephenson , zsh-workers@zsh.org References: <20120629094045.GA96213@redoubt.spodhuis.org> <20120629195254.5dba2156@pws-pc.ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120629195254.5dba2156@pws-pc.ntlworld.com> On 2012-06-29 at 19:52 +0100, Peter Stephenson wrote: > I'm still not really following what you're trying to do, but my guess is > you're not actually trying to unset the variable at all, you're trying > to set it to an empty string. They may sound similar, and they often > have the same effect, but they are different things. If the variable is > unset, it is indeed uncoupled from anything else that's going on, which > is kind of what unset means. So unsetting an unset variable does indeed > have no effect. I'd decided it was a bug because that's what unset means, but setting it again rebinds it to have the same meaning as before, so it can't be meaningfully unset. You can't rebind the variable name to a different internal structure, so at this point the semantics become somewhat messed up. I think that there's a bug here, but deciding what the correct behaviour should be is non-trivial and certainly not worth blocking 5.0.0 for. Fundamentally, in zsh at present, it seems that magic variables can not have their magic purged from them as the names can never truly be unbound, just temporarily made unavailable, yet the same content can be available under other names. For library-level robustness against someone having set a prompt variable (PROMPT3/PS3 for instance) but unbound one of the names, getting back consistent state seems to require setting both names and only caring about the value of which one is set second, so that both names remain available thereafter. If the name could be rebound to another variable and no longer be magic, the current approach would be sane, but it seems that perhaps the correct behaviour should be to ensure that whatever the state of one name, the other name should be in the same state: set, unset, empty, with-content, whatever. Perhaps I've become contaminated with the Pythonic approach of being distinct about the binding of a name to a variable versus the changing of the value of a variable. -Phil