zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <zefram@fysh.org>
To: schaefer@candle.brasslantern.com (Bart Schaefer)
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: cd, pwd and symlinks
Date: Tue, 28 Sep 1999 18:42:46 +0100 (BST)	[thread overview]
Message-ID: <E11W1H5-0001ev-00@crucigera.fysh.org> (raw)
In-Reply-To: <990928164248.ZM21457@candle.brasslantern.com> from Bart Schaefer at "Sep 28, 1999  4:42:47 pm"

Bart Schaefer wrote:
>On Sep 28, 12:07pm, Peter Stephenson wrote:
>} There's some reason why the code was changed
>} to do all changes with absolute path --- maybe to simplify it, hur hur.
>
>As far as I can tell, this is something Zefram changed between 3.1.2 and
>3.1.3, for which no patch was ever posted.

I'm pretty sure it's not.  That's one of the areas of the shell that I
studiously avoided changing.

If I'd designed the shell from scratch, it would match the underlying OS
behaviour, and consequently $PWD wouldn't exist, or at least not in the
form we have it.  $PWD is really an abomination, giving the impression of
an absolute directory structure, which in fact doesn't exist.  Given that
we have to support it, there are basically two sensible ways for it
to work:

1. cd maps directly onto chdir(), doing everything the way the
   filesystem says.  $PWD has no direct effect -- it is equivalent to
   $(pwd), recalculated every time it is referenced.  It always searches
   for a valid absolute pathname referring to the current directory.
   The user must accept that it will sometimes fail (yielding "."),
   and that the pathname returned will not necessarily remain valid,
   but it will always be valid at the moment it is evaluated.

2. $PWD is the shell's canonical idea of its current directory.  cd with
   a relative pathname does text substitution using $PWD, and then does
   a chdir() to the resulting absolute pathname.  pwd just gives $PWD,
   and has an option to do a /bin/pwd-style search instead.  The user
   must accept that the current directory may not be accessible under
   the name in $PWD, and that relative filenames in a cd command have
   completely different semantics from relative filenames everywhere else.

Until 3.1.6, we had a pretty consistent 2.  Now we have a mixture of the
two styles, which isn't working, and making it more complicated isn't
going to help.  Let's just have the two ways of working, with an option
to switch between them.

-zefram


  reply	other threads:[~1999-09-28 17:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5lemfkez1d.fsf@tequila.cs.yale.edu>
1999-09-28 10:07 ` Peter Stephenson
1999-09-28 16:42   ` Bart Schaefer
1999-09-28 17:42     ` Zefram [this message]
1999-09-29  3:29       ` Bart Schaefer
1999-09-29  9:33         ` Peter Stephenson

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=E11W1H5-0001ev-00@crucigera.fysh.org \
    --to=zefram@fysh.org \
    --cc=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).