* pushd @ 1996-10-11 12:34 Peter Stephenson 1996-10-11 13:01 ` pushd Vinnie Shelton 1996-10-11 19:53 ` pushd Bart Schaefer 0 siblings, 2 replies; 19+ messages in thread From: Peter Stephenson @ 1996-10-11 12:34 UTC (permalink / raw) To: Zsh hackers list I know I'm several months behind everyone else, but I've belatedly realised that I find the new pushd behaviour unusable because if you bring an arbitrary directory (say via pushd +2) to the top there's no way of knowing where in the stack the directory you were just in has landed. Since I'm used to being able to go straight back there just by typing `pushd', this is a major flaw. If I use `cd +2' the last directory disappears altogether. I've got to use `pushd -' to get back which is a bit too much for my brain to handle --- plus this time the rearrangement isn't cyclic, so the order gets royally messed up when I'm back in the original directory (to put it another way, the behaviour pushing an existing directory when PUSHD_IGNORE_DUPS is set is now incompatible with pushd +n). In fact, a cyclic rearrangement is just too much for my brain to handle anyway because nothing is where it was. I want pushd to work so that I can leave group symmetry operations inside analysis programmes where they belong rather than thinking about $C_N$ representations every time I change directories. Could we have an option NO_PUSHD_PUTS_INHUMAN_DEMANDS_ON_BRAIN, or something? -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-11 12:34 pushd Peter Stephenson @ 1996-10-11 13:01 ` Vinnie Shelton 1996-10-11 15:13 ` pushd Peter Whaite 1996-10-11 19:53 ` pushd Bart Schaefer 1 sibling, 1 reply; 19+ messages in thread From: Vinnie Shelton @ 1996-10-11 13:01 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list This is just a "Yeah, what he said". message. pws@ifh.de said: > I know I'm several months behind everyone else, but I've belatedly > realised that I find the new pushd behaviour unusable because if you > bring an arbitrary directory (say via pushd +2) to the top there's no > way of knowing where in the stack the directory you were just in has > landed. Since I'm used to being able to go straight back there just > by typing `pushd', this is a major flaw. If I use `cd +2' the last > directory disappears altogether. I've got to use `pushd -' to get > back which is a bit too much for my brain to handle --- plus this > time the rearrangement isn't cyclic, so the order gets royally messed > up when I'm back in the original directory (to put it another way, > the behaviour pushing an existing directory when PUSHD_IGNORE_DUPS is > set is now incompatible with pushd +n). I'm glad you mentioned this, Peter. I've had way too much difficulty with this as well. I end up running 'dirs' all the time. My $.02. --vin ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-11 13:01 ` pushd Vinnie Shelton @ 1996-10-11 15:13 ` Peter Whaite 0 siblings, 0 replies; 19+ messages in thread From: Peter Whaite @ 1996-10-11 15:13 UTC (permalink / raw) To: acs; +Cc: Peter Stephenson, Zsh hackers list Vinnie Shelton said: > > This is just a "Yeah, what he said". message. > > pws@ifh.de said: > > I know I'm several months behind everyone else, but I've belatedly > > realised that I find the new pushd behaviour unusable because if you > > bring an arbitrary directory (say via pushd +2) to the top there's no > > way of knowing where in the stack the directory you were just in has > > landed. Since I'm used to being able to go straight back there just > > by typing `pushd', this is a major flaw. If I use `cd +2' the last > > directory disappears altogether. I've got to use `pushd -' to get > > back which is a bit too much for my brain to handle --- plus this > > time the rearrangement isn't cyclic, so the order gets royally messed > > up when I'm back in the original directory (to put it another way, > > the behaviour pushing an existing directory when PUSHD_IGNORE_DUPS is > > set is now incompatible with pushd +n). > > I'm glad you mentioned this, Peter. I've had way too much difficulty with > this as well. I end up running 'dirs' all the time. Here's another yeah as well. I find `pushd ~N' more to my liking as I can never remember the dir stack order anyway. Its too bad that '~' is such an inconvenient key. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-11 12:34 pushd Peter Stephenson 1996-10-11 13:01 ` pushd Vinnie Shelton @ 1996-10-11 19:53 ` Bart Schaefer 1996-10-15 12:45 ` pushd Peter Stephenson 1 sibling, 1 reply; 19+ messages in thread From: Bart Schaefer @ 1996-10-11 19:53 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On Oct 11, 2:34pm, Peter Stephenson wrote: } Subject: pushd } } I know I'm several months behind everyone else, but I've belatedly } realised that I find the new pushd behaviour unusable Nevertheless, tcsh and bash behave the same way ... } bring an arbitrary directory (say via pushd +2) to the top there's no } way of knowing where in the stack the directory you were just in has } landed. Sure there is. For `pushd +N', you can always get the original stack ordering back with `pushd -(N-1)'. It annoys me a little bit that using `pushd -0' changes directory whereas `pushd +0' does not -- that is, I think the current directory should be position zero in either direction, not just when counting from the left -- but once again that's the way that bash does it (tcsh doesn't accept `-N' at all). (The above assumes, of course, that PUSHD_MINUS isn't set.) } If I use `cd +2' the last directory disappears altogether. I've always wondered whether the benefits of connecting `cd' to the directory stack are worth it. However, this is what I'd call the expected behavior; you didn't ask for the current directory to be put on the stack. } (to put it another way, the } behaviour pushing an existing directory when PUSHD_IGNORE_DUPS is set } is now incompatible with pushd +n). Ah, now that *is* a problem, because PUSHD_IGNORE_DUPS chops entries out of the middle of the stack. In that case you really do lose track of where you are and where you came from. Is the following more like the behavior you want? function pushd() { setopt localoptions case $1 in +*) setopt pushdignoredups builtin pushd ${${=$(dirs)}[$1]} ;; -*) setopt pushdignoredups builtin pushd ${${=$(dirs)}[$1-1]} ;; *) builtin pushd $* ;; esac } -- 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-11 19:53 ` pushd Bart Schaefer @ 1996-10-15 12:45 ` Peter Stephenson 1996-10-15 17:08 ` pushd Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Peter Stephenson @ 1996-10-15 12:45 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > Is the following more like the behavior you want? Well, if I adapt your suggestion to: pushd () { setopt localoptions globsubst unsetopt ksharrays case $1 in +*) setopt pushdignoredups builtin pushd ${${=$(dirs)}[$1+1]};; -*) setopt pushdignoredups builtin pushd ${${=$(dirs)}[$1-1]};; *) builtin pushd $*;; esac } (since I need ~ expansion and I don't want to count entry 0 from dirs in the array indexing) I seem to get basically what I want. It's yet another case of running very hard to stay in the same place. -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-15 12:45 ` pushd Peter Stephenson @ 1996-10-15 17:08 ` Bart Schaefer 1996-10-15 17:34 ` pushd Zoltan Hidvegi 1996-10-15 18:45 ` pushd Anthony Heading 0 siblings, 2 replies; 19+ messages in thread From: Bart Schaefer @ 1996-10-15 17:08 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On Oct 15, 2:45pm, Peter Stephenson wrote: } Subject: Re: pushd } } "Bart Schaefer" wrote: } > Is the following more like the behavior you want? } } Well, if I adapt your suggestion to: } } pushd () { } setopt localoptions globsubst } unsetopt ksharrays [...] } } } } (since I need ~ expansion and I don't want to count entry 0 from dirs } in the array indexing) Tilde expansion? Oh, yeah, I forgot that dirstack entries (or rather, "dirs" output) are tilde-abbreviated. I wasn't anywhere near my home directory when I was playing with this. } I seem to get basically what I want. It's yet } another case of running very hard to stay in the same place. Yes, I certainly know how you feel. Most of the contents of my .z* files are there just to help me lean into the hurricane. I'd never noticed the (previous) discrepancy between zsh and csh/bash directory stack behavior, and I'd similarly not yet noticed the change, because I long ago took to opening a new xterm anytime I'll be spending more than a few seconds in another directory. So my stack never gets more than about 3 entries deep. But I've done plenty of my own griping about changes made to features that other people didn't use/notice. I'm with you for a PUSHD_CYCLE option, set by default, which when not set would give the old zsh behavior. Is the following the ChangeLog entry for pushd becoming cyclic? Has it really been that long ago? March/April 1995 * pushd/popd changes from Anthony Heading <aheading@jpmorgan.com> -- 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-15 17:08 ` pushd Bart Schaefer @ 1996-10-15 17:34 ` Zoltan Hidvegi 1996-10-16 5:38 ` pushd Bart Schaefer 1996-10-15 18:45 ` pushd Anthony Heading 1 sibling, 1 reply; 19+ messages in thread From: Zoltan Hidvegi @ 1996-10-15 17:34 UTC (permalink / raw) To: schaefer; +Cc: Zsh workers list > Is the following the ChangeLog entry for pushd becoming cyclic? Has it > really been that long ago? > > March/April 1995 > > * pushd/popd changes from Anthony Heading <aheading@jpmorgan.com> You can find this under: Fri May 3 03:38:28 1996 Zoltán Hidvégi <hzoli@cs.elte.hu> ... * merged the patches from beta15-hzoli14. Here is the ChangeLog for that: March/April 1995 And here comes a long list. So it is really old but it got into the baseline only in beta17. Zoltan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-15 17:34 ` pushd Zoltan Hidvegi @ 1996-10-16 5:38 ` Bart Schaefer 1996-10-16 8:42 ` pushd Zefram 1996-10-16 12:42 ` pushd Peter Stephenson 0 siblings, 2 replies; 19+ messages in thread From: Bart Schaefer @ 1996-10-16 5:38 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers Well, that was remarkably easy, especially as compared to John Cooper's popd problems. --- Doc/zsh.texi.0 Tue Oct 8 10:30:07 1996 +++ Doc/zsh.texi Tue Oct 15 22:32:02 1996 @@ -5054,6 +5054,15 @@ If set, @dfn{parameter expansion}, @dfn{command substitution} and @dfn{arithmetic expansion} is performed in prompts. +@item PUSHD_CYCLE +@cindex directory stack, cycling entries +@pindex PUSHD_CYCLE +When set, @code{pushd +@var{n}} and @code{pushd -@var{n}} (for integer +@var{n}) rotate the directory stack to bring the @var{n}th directory to +the top. Otherwise the @var{n}th element is moved to the top of the stack +without reordering other directories, which was the behavior in past +versions of @code{zsh}. + @item PUSHD_IGNORE_DUPS @cindex directory stack, ignoring dups @pindex PUSHD_IGNORE_DUPS @@ -6162,7 +6171,7 @@ The third form of @code{pushd} changes directory by rotating the directory list. An argument of the form @code{+n} identifies a stack entry by counting from the left of the list shown by the @code{dirs} command, starting with -zero. An argument of the form @samp{-n} counts from the right. If the +zero. An argument of the form @code{-n} counts from the right. If the @code{PUSHD_MINUS} option is set, the meanings of @code{+} and @code{-} in this context are swapped. --- Doc/zshoptions.man.0 Tue Oct 8 10:30:08 1996 +++ Doc/zshoptions.man Tue Oct 15 21:12:47 1996 @@ -436,6 +436,12 @@ If set, \fIparameter expansion\fP, \fIcommand substitution\fP and \fIarithmetic expansion\fP is performed in prompts. .TP +\fBPUSHD_CYCLE\fP +When set, \fBpushd +n\fP and \fBpushd -n\fP (for integer \fIn\fP) rotate the +directory stack to bring the \fIn\fPth directory to the top. Otherwise the +\fIn\fPth element is moved to the top of the stack without reordering other +directories, which was the behavior in past versions of \fBzsh\fP. +.TP \fBPUSHD_IGNORE_DUPS\fP Don't push multiple copies of the same directory onto the directory stack. .TP --- Src/builtin.c.0 Tue Oct 8 10:30:08 1996 +++ Src/builtin.c Tue Oct 15 16:37:42 1996 @@ -1262,7 +1262,7 @@ char *new_pwd, *s; int dirstacksize; - if (func == BIN_PUSHD) + if (func == BIN_PUSHD && isset(PUSHDCYCLE)) rolllist(dirstack, dir); new_pwd = remnode(dirstack, dir); --- Src/globals.h.0 Tue Oct 8 10:30:09 1996 +++ Src/globals.h Tue Oct 15 16:36:33 1996 @@ -764,6 +764,7 @@ {"privileged", 'p', 'p', OPT_SPECIAL}, {"promptcr", x'V', 0, OPT_ALL}, {"promptsubst", 0, 0, OPT_EMULATE|OPT_KSH}, + {"pushdcycle", 0, 0, OPT_ALL}, {"pushdignoredups", 0, 0, 0}, {"pushdminus", 0, 0, 0}, {"pushdsilent", 'E', 0, 0}, --- Src/zsh.h.0 Tue Oct 8 10:30:10 1996 +++ Src/zsh.h Tue Oct 15 16:38:17 1996 @@ -1134,6 +1134,7 @@ PRIVILEGED, PROMPTCR, PROMPTSUBST, + PUSHDCYCLE, PUSHDIGNOREDUPS, PUSHDMINUS, PUSHDSILENT, -- 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 5:38 ` pushd Bart Schaefer @ 1996-10-16 8:42 ` Zefram 1996-10-16 17:36 ` pushd Bart Schaefer 1996-10-16 12:42 ` pushd Peter Stephenson 1 sibling, 1 reply; 19+ messages in thread From: Zefram @ 1996-10-16 8:42 UTC (permalink / raw) To: schaefer; +Cc: hzoli, zsh-workers >+ {"pushdcycle", 0, 0, OPT_ALL}, I think this should have OPT_EMULATE too. -zefram ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 8:42 ` pushd Zefram @ 1996-10-16 17:36 ` Bart Schaefer 1996-10-16 18:10 ` pushd Zefram 0 siblings, 1 reply; 19+ messages in thread From: Bart Schaefer @ 1996-10-16 17:36 UTC (permalink / raw) To: Zefram; +Cc: hzoli, zsh-workers On Oct 16, 9:42am, Zefram wrote: } Subject: Re: pushd } } >+ {"pushdcycle", 0, 0, OPT_ALL}, } } I think this should have OPT_EMULATE too. Probably right, unless what you're trying to emulate is zsh 2.x. :-) (Baroque idea: Have `emulate' take a version number and set the options to behave like that version of zsh. No, I'm not serious.) There are two remaining pushd oddities: (1) pushd with no args on an empty dirstack acts like pushdtohome, even when pushdtohome is not set. Perhaps the code in my patch: if (func == BIN_POPD && !nextnode(firstnode(dirstack))) { zwarnnam(nam, "directory stack empty", NULL, 0); return NULL; } Should instead read: if ((func == BIN_POPD || (func == BIN_PUSHD && unset(PUSHDTOHOME))) && !nextnode(firstnode(dirstack))) { zwarnnam(nam, "directory stack empty", NULL, 0); return NULL; } (2) pushd to a dirstack element that names a nonexistent directory has inconsistent behavior, and can put the current directory into the stack multiple times: zagzig% dirs /usr/src/local/zsh/zsh-3.0.1-test3 /tmp/remthis /tmp zagzig% rmdir /tmp/remthis zagzig% pushd +1 pushd: no such file or directory: /tmp/remthis zagzig% dirs /usr/src/local/zsh/zsh-3.0.1-test3 /tmp/remthis /tmp zagzig% pushd pushd: no such file or directory: /tmp/remthis zagzig% dirs /usr/src/local/zsh/zsh-3.0.1-test3 /usr/src/local/zsh/zsh-3.0.1-test3 /tmp 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). -- 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 17:36 ` pushd Bart Schaefer @ 1996-10-16 18:10 ` Zefram 1996-10-16 21:16 ` pushd Bart Schaefer 1996-10-16 22:28 ` pushd Zoltan Hidvegi 0 siblings, 2 replies; 19+ messages in thread From: Zefram @ 1996-10-16 18:10 UTC (permalink / raw) To: schaefer; +Cc: hzoli, zsh-workers >(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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 18:10 ` pushd Zefram @ 1996-10-16 21:16 ` Bart Schaefer 1996-10-17 13:22 ` pushd Anthony Heading 1996-10-16 22:28 ` pushd Zoltan Hidvegi 1 sibling, 1 reply; 19+ messages in thread From: Bart Schaefer @ 1996-10-16 21:16 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 21:16 ` pushd Bart Schaefer @ 1996-10-17 13:22 ` Anthony Heading 1996-10-17 13:47 ` pushd Peter Stephenson 1996-10-17 17:01 ` pushd Bart Schaefer 0 siblings, 2 replies; 19+ messages in thread From: Anthony Heading @ 1996-10-17 13:22 UTC (permalink / raw) To: schaefer; +Cc: zefram, zsh-workers Bart wrote: > } 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: > [...] > and I agree you have a bit of a mess. Hmmph. I guess I'm not supposed to take that personally. :-) Seriously, the explanation above is exactly right, and I don't think it's as messy as all that -- it's just not documented or restructured. And BTW the reason that it's not documented is that RC didn't want to incorporate any of the versions of this patch that I produced, so I tried to keep the patch as small as possible so that it wouldn't cause Zoltan too much trouble in maintaining his releases. But once you've got the hang of the fact that $PWD is pushed onto the stack, the rest follows. And pushing $PWD is a good idea, since you might be executing pushd, or have AUTOPUSHD set, or whatever, and you don't need to specialcase. But Bart's changes to popd make complete sense -- in retrospect I've no idea why I didn't do the obvious optimisation. I'm still puzzled, though, as to why Peter et al want this PUSHD_CYCLE option. The reason it's so easy to implement is that it is, in effect, simply aliasing pushd=cd. Completely altering the de-facto standard definition of a shell command is something on balance to be avoided. To repeat my suggestion, why not just make cd +n push the current directory? Then it'll do exactly the same as pushd, while being two less chars to type, and not requiring extra emulation parameters. Anthony ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-17 13:22 ` pushd Anthony Heading @ 1996-10-17 13:47 ` Peter Stephenson 1996-10-17 17:01 ` pushd Bart Schaefer 1 sibling, 0 replies; 19+ messages in thread From: Peter Stephenson @ 1996-10-17 13:47 UTC (permalink / raw) To: Zsh hackers list Anthony Heading wrote: > I'm still puzzled, though, as to why Peter et al want this PUSHD_CYCLE > option . The reason it's so easy to implement is that it is, in > effect, simply aliasing pushd=cd. Completely altering the de-facto > standard definition of a shell command is something on balance to be > avoided. To repeat my suggestion , why not just make cd +n push the > current directory? Then it'll do exactly the same as pushd, while > being two less chars to type, and not requiring extra emulation > parameters. But it isn't equivalent, because cd doesn't push things down on the stack, just bring them to the top replacing whatever's there, unless you have autopushd set, which I don't. I don't want cd to push things on the stack, that's why we have pushd. I want cd to change directories and pushd to push directories. I don't think that's unreasonable. -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-17 13:22 ` pushd Anthony Heading 1996-10-17 13:47 ` pushd Peter Stephenson @ 1996-10-17 17:01 ` Bart Schaefer 1 sibling, 0 replies; 19+ messages in thread From: Bart Schaefer @ 1996-10-17 17:01 UTC (permalink / raw) To: Anthony Heading; +Cc: zsh-workers On Oct 17, 2:22pm, Anthony Heading wrote: } Subject: Re: pushd } } Bart wrote: } > } I have to say, the cd functions are a real mess. } > } > and I agree you have a bit of a mess. } } Hmmph. I guess I'm not supposed to take that personally. :-) A former employer of mine, venturing rather too far into the Dilbert Zone, once sent thirty of us to a three-day seminar whose main focus was how to have code reviews without taking them personally. A fine idea, but not one that requires three days to elaborate upon. } Bart wrote: } > 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 [push] the current directory } } [...] once you've got the } hang of the fact that $PWD is pushed onto the stack, the rest follows. And } pushing $PWD is a good idea, since you might be executing pushd, or have } AUTOPUSHD set, or whatever, and you don't need to specialcase. The question is not, "Why is $PWD pushed onto the stack?" The question is, "Why is $PWD always popped off the stack?" To save a couple hundred bytes? If you just leave it there, then every routine sees the stack the same way; even fewer special cases. It does mean the you have to setdata() whenever you change directories, but that's less effort than pushing/popping and easier to isolate. Yes, it does introduce the possibility that a careless programmer will let $PWD and the top of the stack get out of sync. But that's why we have this list, and particularly why we have Zoltan. And it would be possible to have a special var-get-fn for PWD that returns the top of the dirstack. (There's already a special var-set-fn to prevent PWD from being changed.) If PWD just refers to the top of the stack, you've saved your bytes again and simplified some other code. } But Bart's changes to popd make complete sense -- in retrospect I've no } idea why I didn't do the obvious optimisation. Usually the answer to those sorts of questions is, "because it was obvious." :-) It's easy to get so deep into the mechanics that places where mechanics could be avoided simply go past overhead. } I'm still puzzled, though, as to why Peter et al want this PUSHD_CYCLE } option. The reason it's so easy to implement is that it is, in effect, } simply aliasing pushd=cd. Ah, but as Peter already pointed out, that's not the effect. Its the most similar to pushd() { setopt localoptions autopushd pushdignoredups; cd $* } except that the `pushdignoredups' part only sometimes applies. -- 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 18:10 ` pushd Zefram 1996-10-16 21:16 ` pushd Bart Schaefer @ 1996-10-16 22:28 ` Zoltan Hidvegi 1 sibling, 0 replies; 19+ messages in thread From: Zoltan Hidvegi @ 1996-10-16 22:28 UTC (permalink / raw) To: Zefram; +Cc: schaefer, zsh-workers > Oh, what was the reasoning behind requiring "(UID=123; foo)" where > "UID=123 foo" used to work? I liked the exporting syntax. It was the simplest way to handle special parameters. If you say parameter=value command the given environment variable is always set to value even if it is a special parameter or integer or anything. So now UID=hzoli printenv UID says hzoli. In case of UID it may net be the desired behaviour but in some other cases this makes things simpler. I also liked the exporting syntax but I often tried to use that to a zsh function or to a builtin which caused irreversibly lost privileges. Offtopic but note that USERNAME is much more secure as it now executes initgroups() as well similarily to su username (this is new, zsh-3.0.0 does not do that). A somewhat related question: % ksh $ readonly foo=foo $ foo=bar printenv foo ksh: foo: is read only % zsh % readonly foo=foo % foo=bar printenv foo bar The current bash version behaves similarily but I talked to the bash maintainer and he thinks that the ksh behaviour is the correct one and bash-2.0 will now allow this. Similar question: % ksh $ typeset -i i=12 $ i=foo printenv i 0 Zsh prints foo here. That's why UID=798 command does not work. Zoltan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-16 5:38 ` pushd Bart Schaefer 1996-10-16 8:42 ` pushd Zefram @ 1996-10-16 12:42 ` Peter Stephenson 1 sibling, 0 replies; 19+ messages in thread From: Peter Stephenson @ 1996-10-16 12:42 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > - if (func == BIN_PUSHD) > + if (func == BIN_PUSHD && isset(PUSHDCYCLE)) Is that it???? Thanks anyway, that does just what I want. -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: pushd 1996-10-15 17:08 ` pushd Bart Schaefer 1996-10-15 17:34 ` pushd Zoltan Hidvegi @ 1996-10-15 18:45 ` Anthony Heading 1 sibling, 0 replies; 19+ messages in thread From: Anthony Heading @ 1996-10-15 18:45 UTC (permalink / raw) To: schaefer; +Cc: pws, zsh-workers > I'm with you for a PUSHD_CYCLE option, set by default, which when not > set would give the old zsh behavior. > > Is the following the ChangeLog entry for pushd becoming cyclic? Has it > really been that long ago? > > March/April 1995 > > * pushd/popd changes from Anthony Heading <aheading@jpmorgan.com> Yes, it was about then -- it was in the hzoli releases from the start, I think. I was trying to keep quiet on this one, since I never had a particular axe to grind, but compatibility with other shells seems sensible. The idea was that the "old behaviour" remained available with cd +n, while pushd/popd +n (which used to do the same as cd) moved to bash/csh semantics. I didn't anticipate that this could cause any aggravation, but seemingly it has, for which I apologise. I guess it's because I set AUTOPUSHD, so there really is no lost functionality. Would it make people happy if (optionally?) cd +n pushed the current directory? Then cd +n could be exactly the same as the old pushd +n. Anthony ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: pushd
@ 1996-10-18 13:14 Ray Van Tassle-CRV004
0 siblings, 0 replies; 19+ messages in thread
From: Ray Van Tassle-CRV004 @ 1996-10-18 13:14 UTC (permalink / raw)
To: aheading, schaefer; +Cc: zsh-workers
>
> ________________________________________________________
> To: aheading@jpmorgan.com@INTERNET
> Cc: zsh-workers@math.gatech.edu@INTERNET
> From: schaefer@nbn.com@INTERNET on Thu, Oct 17, 1996 12:48 PM
> Subject: Re: pushd
>
> On Oct 17, 2:22pm, Anthony Heading wrote:
> } Subject: Re: pushd
> }
> } Bart wrote:
> } > } I have to say, the cd functions are a real mess.
> } >
> } > and I agree you have a bit of a mess.
> }
> } Hmmph. I guess I'm not supposed to take that personally. :-)
>
> A former employer of mine, venturing rather too far into the Dilbert Zone,
> once sent thirty of us to a three-day seminar whose main focus was how to
> have code reviews without taking them personally. A fine idea, but not
> one that requires three days to elaborate upon.
Oh, god! I thought it was just us! We just went through the same thing.
But the whole division is going---500-700 people. The first day was
intellectually insulting "california 60's" psycho-babble and typical
argle-barble "map/territory" confusion. I walked out at noon. The week
before, there was a Dilbert about "Whoh! We can't just rush into the
pre-meeting meeting without having a pre-pre-pre meeting to set it up!" So,
guess what we covered in the next 2 days!!!???
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1996-10-18 13:28 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-10-11 12:34 pushd Peter Stephenson 1996-10-11 13:01 ` pushd Vinnie Shelton 1996-10-11 15:13 ` pushd Peter Whaite 1996-10-11 19:53 ` pushd Bart Schaefer 1996-10-15 12:45 ` pushd Peter Stephenson 1996-10-15 17:08 ` pushd Bart Schaefer 1996-10-15 17:34 ` pushd Zoltan Hidvegi 1996-10-16 5:38 ` pushd Bart Schaefer 1996-10-16 8:42 ` pushd Zefram 1996-10-16 17:36 ` pushd Bart Schaefer 1996-10-16 18:10 ` pushd Zefram 1996-10-16 21:16 ` pushd Bart Schaefer 1996-10-17 13:22 ` pushd Anthony Heading 1996-10-17 13:47 ` pushd Peter Stephenson 1996-10-17 17:01 ` pushd Bart Schaefer 1996-10-16 22:28 ` pushd Zoltan Hidvegi 1996-10-16 12:42 ` pushd Peter Stephenson 1996-10-15 18:45 ` pushd Anthony Heading 1996-10-18 13:14 pushd Ray Van Tassle-CRV004
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).