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 EAA02503 for ; Thu, 17 Oct 1996 04:21:01 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id OAA22572; Wed, 16 Oct 1996 14:11:19 -0400 (EDT) Resent-Date: Wed, 16 Oct 1996 14:11:19 -0400 (EDT) From: Zefram Message-Id: <5016.199610161810@stone.dcs.warwick.ac.uk> Subject: Re: pushd To: schaefer@nbn.com Date: Wed, 16 Oct 1996 19:10:53 +0100 (BST) Cc: hzoli@cs.elte.hu, zsh-workers@math.gatech.edu In-Reply-To: <961016103650.ZM30346@candle.brasslantern.com> from "Bart Schaefer" at Oct 16, 96 10:36:50 am X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8278.78 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"c1kpG.0.cW5.7LIPo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2246 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu >(Baroque idea: Have `emulate' take a version number and set the options >to behave like that version of zsh. No, I'm not serious.) I've considered previously what the implications of this would be. A *complete* emulation could be quite mind-boggling: after emulating, say, zsh-3.0.0 you can't get back, because 3.0.0 doesn't know how to emulate versions. You would only ever be able to move the emulation back in time. Would we have to emulate bugs as well? And if we're going to do this, my vote on the interface goes to an assignable ZSH_VERSION parameter. (So your scripts can start with "emulate zsh; ZSH_VERSION=3.1.3".) Oh, what was the reasoning behind requiring "(UID=123; foo)" where "UID=123 foo" used to work? I liked the exporting syntax. Back to more practical matters: >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. I'm beginning to worry that even the patches I >sent yesterday don't work as they should (or rather, that they work only >because both zsfree() and getlinknode() ignore null pointers). I have to say, the cd functions are a real mess. There are at least some comments now, but still it can be difficult to comprehend -- there are *six* locations from which chdir() is called. I think a complete rewrite is in order. -zefram