Symlinks and ..
Andrew Koenig
ark at alice.UUCP
Tue Nov 21 05:15:24 AEST 1989
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
More information about the Comp.unix.questions
mailing list