From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26495 invoked from network); 15 Aug 1998 17:29:30 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 15 Aug 1998 17:29:30 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id NAA02845; Sat, 15 Aug 1998 13:15:49 -0400 (EDT) Resent-Date: Sat, 15 Aug 1998 13:15:49 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980815101754.ZM18872@candle.brasslantern.com> Date: Sat, 15 Aug 1998 10:17:53 -0700 In-Reply-To: <199808150825.IAA06359@tgape.ed.vnet> Comments: In reply to TGAPE! "Re: bug with chpwd/allexport (plus expansion/substitution remarks)" (Aug 15, 8:25am) References: <199808150825.IAA06359@tgape.ed.vnet> X-Mailer: Z-Mail (4.0b.820 20aug96) To: TGAPE! Subject: Re: bug with chpwd/allexport (plus expansion/substitution remarks) Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"7Pgtz2.0.Oi.59Srr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4310 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Aug 15, 8:25am, TGAPE! wrote: } Subject: Re: bug with chpwd/allexport (plus expansion/substitution remarks } } I know this was a while ago, but I frequently lack time... I know what you mean. } Bart Schaefer wrote: } > On Jul 17, 2:42pm, Zefram wrote: } >} Dominik Vogt wrote: } >}> BTW if the second workaround you suggest works, } >}>then it is a bug. The manpage states clearly, that a local variable is } >}>still exported if the ALLEXPORT option is set and the variable was } >}>prviously unset. } >} } >} But with `local', the variable disappears at the end of the function, } > } > That also doesn't affect whether the name is added to the named directory } > hash table. Unsetting the variable doesn't unhash the name; making it a } > local has no effect on this problem whatsoever. } } It doesn't? It seems to in 3.1.1 Indeed, to say "no effect whatsoever" is an overstatement; I was misled by performing my tests with a variable that already had a value. Here's the actual situation: IF a variable is already set to a name that begins with a slash AND THEN a local of the same name is added to the named directory hash table, the result is that the original variable remains in the directory hash table after the function exits. Otherwise, unset of a variable including of a local on exit from the function, removes the corresponding hash entry. There's a slight difference between 3.0.5 and 3.1.4 in the handling of an unset local, illustrated below. I originally tried only the equivalent of namedir4 in test 2, which caused me to make the overstatement excerpted above. Test functions: namedir1 () { setopt localoptions autonamedirs local $1=$2 echo namedir1: $(hash -d | grep \^$1) } namedir2 () { local $1=$2 namedir1 $1 $2 echo namedir2: $(hash -d | grep \^$1) } namedir3 () { local $1 unset $1 namedir1 $1 $2 echo namedir3: $(hash -d | grep \^$1) } namedir4 () { namedir1 $1 $2 echo namedir4: $(hash -d | grep \^$1) } namedir_test () { echo $ZSH_NAME $ZSH_VERSION unset test1 test2=/usr/bin echo TEST 1 namedir1 test1 /etc namedir2 test1 /etc namedir3 test1 /etc namedir4 test1 /etc echo TEST 2 namedir1 test2 /etc namedir2 test2 /etc namedir3 test2 /etc namedir4 test2 /etc } Results with zsh -f: zagzig% namedir_test zsh 3.0.5-extended TEST 1 namedir1: test1=/etc namedir1: test1=/etc namedir2: test1=/etc namedir1: test1=/etc namedir3: namedir1: test1=/etc namedir4: TEST 2 namedir1: test2=/etc namedir1: test2=/etc namedir2: test2=/etc namedir1: test2=/etc namedir3: namedir1: test2=/etc namedir4: test2=/usr/bin zagzig% namedir_test zsh 3.1.4 TEST 1 namedir1: test1=/etc namedir1: test1=/etc namedir2: test1=/etc namedir1: test1=/etc namedir3: namedir1: test1=/etc namedir4: TEST 2 namedir1: test2=/etc namedir1: test2=/etc namedir2: test2=/etc namedir1: test2=/etc namedir3: test2=/usr/bin namedir1: test2=/etc namedir4: test2=/usr/bin Note the difference in the handling of "local" in the namedir3 test from 3.0.5 to 3.1.4. I tend to doubt that this discrepancy is intentional. } Besides, it certainly seems to me that it should; if a variable doesn't } exist, how can a reference to that variable be valid? (Yeah, I know } hashes aren't references to variables, even with autonamedirs, but I'm } trying to look at this from the user's perspective.) I agree with you. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com