From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-request@euclid.skiles.gatech.edu Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id HAA04131 for ; Thu, 17 Oct 1996 07:26:24 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id RAA28032; Wed, 16 Oct 1996 17:16:09 -0400 (EDT) Resent-Date: Wed, 16 Oct 1996 17:16:09 -0400 (EDT) From: "Bart Schaefer" Message-Id: <961016141659.ZM31300@candle.brasslantern.com> Date: Wed, 16 Oct 1996 14:16:58 -0700 In-Reply-To: Zefram "Re: pushd" (Oct 16, 7:10pm) References: <5016.199610161810@stone.dcs.warwick.ac.uk> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: Zefram Subject: Re: pushd Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"q_Pry3.0.wr6.O2LPo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2247 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Oct 16, 7:10pm, Zefram wrote: } Subject: Re: pushd } } Oh, what was the reasoning behind requiring "(UID=123; foo)" where } "UID=123 foo" used to work? I liked the exporting syntax. Can't help you, that's a feature I never use. } >At the moment I've reached the limit of my comprehension of how all of } >this works. Too many functions seem to be freeing nodes from the stack } >-- most notably, bin_cd() frees the top node if cd_get_dest() fails, but } >I don't understand why. The answer appears three lines up, and I just didn't see it. It frees the top of the stack because it pushes the current dir onto the stack before calling cd_get_dest(). } I have to say, the cd functions are a real mess. There are several confusing things here. (1) The current directory isn't kept on the stack (so the stack really is empty if you've never pushd'd); but (2) the first thing bin_cd() does is put the current directory on the stack; so (3) none of the functions that manipulate the stack ever see it in empty state, *except* (4) bin_dirs(), printdirstack(), and dstackent() [in subst.c], which all have to special case ~0 as equivalent to $PWD; and (5) all of this means that cd_new_pwd() and/or bin_cd() have to discard the top of the stack once the other routines are finished. Add to this the ability to shovel random tripe into the stack with: zagzig% dirs none of these need to make sense zagzig% dirs /usr/src/local/zsh/zsh-3.0.1-test3/Src none of these need to make sense zagzig% and I agree you have a bit of a mess. } There are at least } some comments now, but still it can be difficult to comprehend I think the way the stack is manipulated is more confusing than the rest of what's being done. Still ... } there are *six* locations from which chdir() is called. That in itself isn't a bad thing, because those calls are all testing for various permutations of following (or not) the CDPATH and handling link chasing etc. There isn't any more accurate way to detect errors than to attempt the chdir() and go on to the next permutation when it fails. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"