Symlinks and ..

[Andrew Koenig]

In article <12407 at ulysses.homer.nj.att.com>, ekrell at 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 at europa.att.com