Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!bellcore!faline!thumper!ulysses!hector!ekrell
From: ekrell@hector.UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <11412@ulysses.homer.nj.att.com>
Date: 6 Apr 89 17:19:10 GMT
References: <3675@ficc.uu.net> <8136@chinet.chi.il.us>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: ekrell@hector.UUCP (Eduardo Krell)
Organization: AT&T Bell Laboratories
Lines: 30

In article <8136@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:

>Better yet would be a per-process *name* of the current working
>directory stored somewhere, built according the the way you
>happened to get there.

This is what ksh does (it stores it in $PWD). pwd is a ksh builtin
which just prints $PWD. It's harder to do in the kernel because pathnames
can be very long and you don't want to increase the size of the process
structure by that much.

>as a side effect, it would make ".." mean something unsuprising in the
>presence of linked directories.  Is there some reason this isn't done?

You would have to convince the powers to be (BSD and System V folks)
that this is the way ".." should behave. We went through this ".." war
a while ago and there were people on both sides.

We actually changed the meaning of ".." to work the way you want it to.
We also changed getwd() and getcwd() so that instead of opening and
closing ".." until it reaches the root, it looks up in the namei()
cache which holds the component names for all current and root directories
of all processes (thus, you can always look in the cache for the name
of the current working directory by just following a linked list back
to the root). Needless to say, this is much faster than opening and
closing directories.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com