Re: pushd

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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"