Zsh Mailing List Archive
Messages sorted by:
- X-seq: zsh-workers 2247
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Zefram <zefram@xxxxxxxxxxxxxxxxx>
- Subject: Re: pushd
- Date: Wed, 16 Oct 1996 14:16:58 -0700
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: Zefram <zefram@xxxxxxxxxxxxxxxxx> "Re: pushd" (Oct 16, 7:10pm)
- References: <5016.199610161810@xxxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: schaefer@xxxxxxx
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
} 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
/usr/src/local/zsh/zsh-3.0.1-test3/Src none of these need to make sense
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
New male in /home/schaefer:
>N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"
Messages sorted by: