From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 10 May 2000 08:51:25 +0000
From: Douglas A. Gwyn DAGwyn@null.net
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Topicbox-Message-UUID: a99ea1b8-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000510085125.ayKmJyFOyvS7rF2Bd2PFaE14SGx5qmUieVq9McLEjPk@z>

rob pike wrote:
> ...  Why in the shell can I cd somewhere but not chdir there?
> Because cd is a bucket of shell magic, but chdir is a system
> call.  Such distinctions don't make a system perspicuous.

A couple of weeks ago we had yet another UNIX user get bit by
the combination of chdir("..") and symbolic links:
	$ pwd
	/a/b
	$ cd ..
	$ rm -rf b
	$ pwd
	/d
	$ ls -l /a
	... b -> /d/e ...
	$ # Drat!  I've just removed the wrong set of files, d/b!

It was this sort of thing, which occurs a *lot* when one maintains
multiple sets of similar files, that long ago drove me to change
BRL's version of the Bourne shell to keep track of the current
working directory so that (a) "pwd" (shell builtin) reflected the
path that had been used to reach the CWD and (b) "cd" (shell
builtin) would handle a ".." path component by removing the deepest
preceding ordinary component (other details were also taken care of).
In actual use, this behavior was much nicer than the original
behavior (that merely passed cd's argument to kernel chdir() and
had to reconstruct a path for "pwd" by massive kludgery in user mode)!

>>From that experience I concluded that the current working directory
ought to be maintained by the kernel as a path, not (just) an inode
index, and chdir() should canonicalize the path as described above.
(There doesn't seem to be any need to test whether the target node
exists; that will turn up later when a file is opened.)  getcwd()
then has a near-trivial implementation, and user-mode utilities
can implement "cd" and "pwd" by simply making system calls.

Sorry for the long story, but I think it has some bearing on the
question of the "right" way to do "bind" etc.