zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zefram <zefram@dcs.warwick.ac.uk>
Cc: zsh-workers@math.gatech.edu
Subject: Re: pushd
Date: Wed, 16 Oct 1996 14:16:58 -0700	[thread overview]
Message-ID: <961016141659.ZM31300@candle.brasslantern.com> (raw)
In-Reply-To: Zefram <zefram@dcs.warwick.ac.uk> "Re: pushd" (Oct 16,  7:10pm)

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"


  reply	other threads:[~1996-10-16 21:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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                 ` Bart Schaefer [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=961016141659.ZM31300@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=schaefer@nbn.com \
    --cc=zefram@dcs.warwick.ac.uk \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).