zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: cd, pwd and symlinks
Date: Tue, 28 Sep 1999 16:42:47 +0000	[thread overview]
Message-ID: <990928164248.ZM21457@candle.brasslantern.com> (raw)
In-Reply-To: <9909281007.AA22813@ibmth.df.unipi.it>

On Sep 28, 12:07pm, Peter Stephenson wrote:
} Subject: Re: cd, pwd and symlinks
}
} "Stefan Monnier" wrote:
} >That's indeed what I'm complaining about.  The default behavior is very
} >non-unixish which is surprising for a unix-only tool.
} 
} In that case, ksh is non-UNIXish too, since it has this logical path
} feature on by default.  (Plus it's still able to change up from a
} no-longer-existent directory, which zsh isn't after the last round of
} cd changes, but we had this discussion at length some months ago.)

Hm.  I thought "cd .." was only supposed to fail if chasedots was set.
"cd ." or "cd ../$PWD:t" are supposed to fail if the destination doesn't
exist.  But this is a side-effect of "cd .." turning into "cd $PWD/.."
plus the rule that "cd /some/missing/directory/.." is supposed to fail,
isn't it.  Argh.
 
} > But how hard would it be to have `pwd' do a stat("$PWD") and stat(".")
} > and compare the inode to make sure the current $PWD is still valid ?
} 
} It does seem that this could be improved.

I can't decide whether I object to this ... but perhaps it should at least
not happen when ksh emulation is in effect?

} This isn't perfect, since unless you run pwd, the shell doesn't know if the
} path to the current directory became invalid and a cd can still fail, but
} at least it gives you a natural way of fixing it.

A bit confusing, though, isn't it?

zsh% cd /tmp/test
zsh% cd subdir
zsh: No such file or directory: subdir
zsh% pwd
/tmp/renamed
zsh% cd subdir
zsh% 

If there were much elapsed time at all between the first two cd's, the
poor user might not remember where he was before the pwd, and would have
no idea what was going on.

And finally, `dirs` still outputs the previous value of PWD.

} 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 sure other people will have completely different ideas, they always do
} with directories.

Indeed.  I may have a look at this later today if I get a chance.  I'm
thinking that (a) pwd should do something more like cd_new_pwd() (but not
including calling chpwd) if it can't stat(pwd), and (b) cd should try
harder, perhaps implicitly behaving as if chasedots, if it can't stat(pwd).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


  reply	other threads:[~1999-09-28 16: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 [this message]
1999-09-28 17:42     ` Zefram
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=990928164248.ZM21457@candle.brasslantern.com \
    --to=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).