From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18366 invoked from network); 19 May 2001 22:16:45 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 19 May 2001 22:16:45 -0000 Received: (qmail 7170 invoked by alias); 19 May 2001 22:16:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14395 Received: (qmail 7150 invoked from network); 19 May 2001 22:16:37 -0000 To: zsh-workers@sunsite.auc.dk (Zsh hackers list), Richard Curnow Subject: Re: PATCH: Re: zsh4.0.1-pre4 : backticks fail if SHLVL nonexistant In-reply-to: ""Bart Schaefer""'s message of "Fri, 18 May 2001 21:13:26 -0000." <1010518211326.ZM19366@candle.brasslantern.com> Date: Sun, 20 May 2001 00:16:36 +0100 From: Peter Stephenson Message-Id: <20010519231637.16348139CF@pwstephenson.fsnet.co.uk> "Bart Schaefer" wrote: > There's some stuff going on here with `outputradix' that I'm not sure is > correct. setiparam() was ignoring the outputradix, setnparam() was using > it; maybe that's because only setnparam() gets called from the math code? Yes, setiparam() doesn't need it. On the other problem: > Richard Curnow wrote: > > zshparam.1 says that setting manpath will change MANPATH and vice versa. > > If I change MANPATH, I don't see manpath getting changed. > > You haven't unset that in your .zshenv too, have you? In that case it will > (temporarily) lose its special connection to $manpath. This seems to be a > bug, because it happens even if $manpath is never unset. I'm no longer convinced this is even a bug, if this is really what the problem is. The code quite explicitly unsets both of such a pair --- the connection isn't lost, but manpath remains unset when you set MANPATH, so you have to set both. For user-tied variables with `typeset -T', the documentation is clear about this, though it isn't explicit for pre-defined path variables. It's tricky to have them only unsetting one of a pair, which causes a lot of grief with the internal state. Maybe the answer is to make sure `createparam' is called for the other value if it is also unset? -- Peter Stephenson Work: pws@csr.com Web: http://www.pwstephenson.fsnet.co.uk