Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!rutgers!att!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.unix.questions
Subject: Re: Symlinks and ..
Message-ID: <10168@alice.UUCP>
Date: 20 Nov 89 18:15:24 GMT
References: <2755@munnari.oz.au> <12407@ulysses.homer.nj.att.com>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 27

In article <12407@ulysses.homer.nj.att.com>, ekrell@hector.UUCP (Eduardo Krell) writes:

> ".." should be treated as a logical operator that moves you one level
> closer to the root by stripping the last component off your current
> working directory (which is whatever path you used to get to where
> you are). This preserves the "/usr/foo/bar/.. == /usr/foo" paradigm.

That's one viewpoint, and it has advantages and disadvantages.

For example, most C preprocessors go to some effort to ensure that
pathnames in #include statements are interpreted relative to the
directory that contains the file with the #include statement in it.

Suppose, for instance, that a directory has subdirectories foo
and bar and a file in foo says  #include "../foo/x.h" .  It is
important to be certain that the x.h included is really the one
in the foo subdirectory.

If you have a system that treats .. as a `logical operator,' then
the x.h that gets included might depend on what directory you
happened to visit before you invoked the preprocessor.

In other words, treating .. as a `logical operator' doesn't solve
the problem, it just moves it to another place.
-- 
				--Andrew Koenig
				  ark@europa.att.com