RE: pushd

RE: pushd

[Ray Van Tassle-CRV004]

> 
> ________________________________________________________
> 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!!!???

Re: pushd

[Bart Schaefer]

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"

Re: pushd

[Peter Stephenson]

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.

Re: pushd

[Anthony Heading]

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

Re: pushd

[Zoltan Hidvegi]

> 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

Re: pushd

[Bart Schaefer]

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"

Re: pushd

[Zefram]

>(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

Re: pushd

[Bart Schaefer]

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"

Re: pushd

[Peter Stephenson]

"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.

Re: pushd

[Zefram]

>+    {"pushdcycle",	 	0,    0,    OPT_ALL},

I think this should have OPT_EMULATE too.

-zefram

Re: pushd

[Bart Schaefer]

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"

Re: pushd

[Anthony Heading]

> 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

Re: pushd

[Zoltan Hidvegi]

> 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

Re: pushd

[Bart Schaefer]

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"

Re: pushd

[Peter Stephenson]

"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.

Re: pushd

[Bart Schaefer]

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"

Re: pushd

[Peter Whaite]

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.

Re: pushd

[Vinnie Shelton]

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

pushd

[Peter Stephenson]

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.