From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20939 invoked from network); 15 Sep 2000 16:36:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Sep 2000 16:36:53 -0000 Received: (qmail 10529 invoked by alias); 15 Sep 2000 16:36:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12810 Received: (qmail 10522 invoked from network); 15 Sep 2000 16:35:57 -0000 From: "Bart Schaefer" Message-Id: <1000915163540.ZM17226@candle.brasslantern.com> Date: Fri, 15 Sep 2000 16:35:39 +0000 In-Reply-To: <000914112009.ZM15936@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "Re: PATCH: "typeset -m" plays havoc" (Sep 14, 11:20am) References: <005101c01e6c$8e67ea50$21c9ca95@mow.siemens.ru> <1000914173545.ZM15847@candle.brasslantern.com> <000914112009.ZM15936@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: "typeset -m" plays havoc MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 14, 11:20am, Bart Schaefer wrote: } } Bad Things happen in every version of zsh back to 2.4 if you specify other } type-declaration flags with -m. Staring at this for a bit convinced me that, at least in recent versions of zsh, this can't really have anything to do with `-m'. What it means is that zsh is not robust in the face of certain "nonsense" typesets of variables that it uses -- any bad thing you can make happen with `-m' it should be possible to make happen without it. Here's an example: erase_PS1() { typeset PS1 prompt PROMPT } Run that function, and your prompt will disappear, even though all it does (supposedly) is declare local parameters with the same names. (This bug can't happen in older versions where those parameters are "special".) The bug doesn't happen if you use `typeset PROMPT prompt PS1', but with any other ordering you erase all three by making any two or more of them local. Similar things can be caused to happen to any of the other non-special, scalar variables that are "tied" (PS2/PROMPT2, histchars/HISTCHARS, etc.) as long as you make them local in the right (er, wrong?) order. Another example: flush_history() { typeset HISTSIZE } In fact, the above examples cover all the bad behavior that caused me to notice the problem with `typeset -m' in the first place. Other crashes happen when changing the type of assorted variables that zsh uses. Here's a good one: PS1='%m%# ' HOST=() If HOST is an empty array and any prompt-expansion string uses "%m", zsh will dump core. This is new as of zsh-workers/12247. Next there appears to be a bad interaction between auto-zmodloaded special parameters and builtin.c:typeset_single(). Normally typeset_single() will choke with "can't change type of a special parameter", but that appears to be tested too early -- the parameter may come into existence because of autoloading between the time the PM_SPECIAL flag is tested and the time the change-of-type is attempted. This leads to a core dump. This does look like a bug strictly with `-m', having to do with the way that the parameter hash table is searched when doing the pattern match: The auto- loaded parameters are in the table but have none of their flags set yet. That's all I have time to hunt around for right now, but it does look as if it's not necessary to force `typeset -m' to work on globals. AFAICT, the reason it worked this way in previous versions was because of the parameter table search: Since you can't possibly refer to a non-existing parameter with `typeset -m', you must therefore be referring to the one that already exists. Now that we have `+g', though, there's no reason one can't say "find this global parameter and force it to be local". So I'll send a revised patch (a subset of Andrej's 12806, really) as soon as I have time to revise the doc slightly to match. That patch probably *won't* address the list of problems above, though ... -- 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