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 UAA25687 for ; Sun, 3 Nov 1996 20:06:53 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id DAA05688; Sun, 3 Nov 1996 03:50:03 -0500 (EST) Resent-Date: Sun, 3 Nov 1996 03:50:03 -0500 (EST) From: "Bart Schaefer" Message-Id: <961103005340.ZM25904@candle.brasslantern.com> Date: Sun, 3 Nov 1996 00:53:40 -0800 In-Reply-To: Zoltan Hidvegi "Re: pushdcycle and pushdignoredups" (Nov 2, 1:56am) References: <199611020056.BAA00431@hzoli.ppp.cs.elte.hu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: Zoltan Hidvegi Subject: Re: pushdcycle and pushdignoredups Cc: zsh-workers@math.gatech.edu (Zsh hacking and development) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"xzai-.0.oO1.xo5Vo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2316 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 2, 1:56am, Zoltan Hidvegi wrote: } Subject: Re: pushdcycle and pushdignoredups } } Bart wrote: } > As far as I can tell, the patch already works exactly as it should } } Well, examining it again I confess that there seems to be no problem with } that patch. But is it really necessary? Isn't Functions/pushd enough for } those who prefer the old behaviour? I don't have a strong opinion on that; others can speak up (Peter?). I note for your consideration that a function solution can't be put under the control of the "emulate" command for purposes of other functions that want to use "pushd" in a specific way. (Aside: Isn't there a bug in Functions/pushd ? It says: setopt localoptions emulate -R zsh but "emulate -R zsh" will unsetopt localoptions again.) } Generally I do not like to add a } feature which can be achieved using existing shell tools. Since this } particular case adds so little extra code I am convicable that this feature } may be worth those extra few bytes but where is the border? One place (though not the only one) where I'd draw a line is at adding a new builtin. When the existing-tools solution requires that a builtin be redefined, as in this case, I'm a bit more inclined to add the feature so that scripts and functions can use it without having to become dependent on other scripts or functions. (Aside #2: Does anybody wish there were an equivalent of "localoptions" that applied to functions and aliases, so that autoloads could blow away all the possible screwy redefinitions of builtins from their environment, yet have them magically restored when the function exits?) Except for the magic ~1 ~2 etc. syntax, the entire functionality of the directory stack and pushd/popd/dirs can be achieved with "echo", "cd" and array assignment. Down that road lies the "rc" shell, but we long ago turned away from that. } Also the number of options in zsh is already large enough to frighten an } average user. Which is why we changed `setopt` output to hide most of them most of the time, right? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern