From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11727 invoked from network); 18 Sep 2000 15:52:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Sep 2000 15:52:38 -0000 Received: (qmail 5286 invoked by alias); 18 Sep 2000 15:51:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12834 Received: (qmail 5279 invoked from network); 18 Sep 2000 15:51:56 -0000 From: "Bart Schaefer" Message-Id: <1000918154526.ZM29557@candle.brasslantern.com> Date: Mon, 18 Sep 2000 15:45:25 +0000 In-Reply-To: <002a01c0214c$276649e0$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "Parameter aliasing? RE: PATCH: "typeset -m" plays havoc" (Sep 18, 12:40pm) References: <002a01c0214c$276649e0$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: "Andrej Borsenkow" , Subject: Re: Parameter aliasing? RE: PATCH: "typeset -m" plays havoc MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 18, 12:40pm, Andrej Borsenkow wrote: } Subject: Parameter aliasing? RE: PATCH: "typeset -m" plays havoc } } > > erase_PS1() { typeset PS1 prompt PROMPT } } } The only clean general way to do it is to introduce real aliases } instead of separate parameters internally referencing the same value. How about this as an alternate solution: Along with the shared pointer for the value of the "tied" parameters, keep track of the locallevel whenever any one of the parameters is made local. When unwinding, only reset the shared pointer if the tracked locallevel is >= the current locallevel, and in that case also reset the tracked locallevel to one less than the current locallevel. That way, all the "tied" parameters are reset at most once as each function is unwound. (I note in passing that parameters created with `typeset -T' become un- tied when either of them is made local, but special tied parameters like path/PATH do not.) } [With aliases] first typeset would save original value and two others } would simply do nothing (well, they would actually print parameters } value. But there is no real way to avoid it). I'm not very happy about this idea, particularly if there's no way to avoid that side-effect. If it can't be made to work "as if" there are separate but "tied" parameters, I'd rather keep hunting for another solution. It sounds like it has a lot of potential to interact badly with the PM_HIDE mechanism, too. Using `typeset -h' is a workaround for the problem, by the way: test_PS1() { typeset -h prompt PROMPT typeset PS1 } As to these issues: } One point to decide is: should 'unset alias' remove parameter itself } (with all aliases) or just unset current alias? There's a bigger question than that: Which name *is* "the parameter itself" and which are merely aliases? Or are none of them really the parameter? It can't just unset the alias, because the shell has to behave "as if" the parameter really were unset; e.g., if you unset PROMPT, zsh should stop printing a top-level prompt, until such time as you assign to one of PS1, prompt, or PROMPT. It can't "forget about" the alias, because `unset PROMPT; PROMPT=foo' has to retain the side-effect of `PS1=foo'. It's an incompatible change to unset them all when any of them is unset, though realistically, probably not a change that anyone would notice. } And if we want user-defined aliases? If we're going to go that way, we should implement ksh namerefs instead. (Except I don't know what happens when you assign to a nameref; does it assign to the referenced variable, or change the name to which the ref refers?) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net