Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.bugs.4bsd
Subject: Re: find(1) and symbolic links
Message-ID: <1158@brl-tgr.ARPA>
Date: Mon, 2-Sep-85 05:07:26 EDT
Article-I.D.: brl-tgr.1158
Posted: Mon Sep  2 05:07:26 1985
Date-Received: Tue, 3-Sep-85 01:40:31 EDT
References: <304@oce-rd1.UUCP> <288f184a.116a@apollo.uucp> <146@graffiti.UUCP>
Organization: Ballistic Research Lab
Lines: 19

> > In all of the 4.2bsd implementations I know about (VAX, Sun, Apollo), find(1) is specifically arranged
> > to not follow symbolic links.  There are a couple of reasons for this:
> >     1) If you follow a symbolic link, it's hard to get back.  Going back to .. doesn't work; instead,
> >        find would have to explicitly keep a stack of the directories it had visited.  While this would
> >        work, it would require find to do a getwd(2) at every directory level, and getwd is pretty slow.
> 
> Why would it require find to do a getwd? The file spelling checker in Kernighan
> and Pike doesn't. All you have to do is build the directory stack on the fly.
> I always assumed find did this rather than depending on ..

Peter is right.  Indeed, most if not all of the utilities in the BRL UNIX
System V emulation for 4.2BSD now avoid doing chdir( ".." ) in order to
avoid problems with symbolic links.  Our SVR2 Bourne shell has been
modified so that "cd .." does what one might expect (trim off rightmost
piece of pathname from current working directory) rather than wander off
in a different direction than was used to enter the directory.  It is
initialized by "cd $HOME" in /usr/5lib/profile (our equivalent of
/etc/profile), to make sure that it thinks you are in the directory as
speicifed in /etc/passwd and not wherever /bin/pwd would say you are.