ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/20/89)
This isn't a question, it's a tip. I have a program which normalises file names so that I can tuck them away in a safe place and use them again later even if I'm in a different directory &c &c. One thing that this program did was to change <prefix>/<directory>/.. to <prefix> The way I handled things like "../../rule" was to prepend the current directory and then just apply this rule, so e.g. /tip/ok/../../vmunix -> /vmunix THIS WAS A MISTAKE. The rule is INVALID when <prefix>/<directory> is a symlink. In my case, there is some piece of black magic so that /tip/ok is really /mount/mullauna/tip/ok so that everything else in the system thinks that /tip/ok/../../vmunix -> /mount/mullauna/vmunix I am less found of symlinks than I used to be.
ekrell@hector.UUCP (Eduardo Krell) (11/20/89)
In article <2755@munnari.oz.au> ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) writes: >I am less found of symlinks than I used to be. Welcome to the club ... ".." 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. Besides, this is the only sensible interpreation of ".." on implementations where ".." does not exist physically as a directory entry (which is not required by POSIX). Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
ark@alice.UUCP (Andrew Koenig) (11/21/89)
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
ekrell@hector.UUCP (Eduardo Krell) (11/21/89)
In article <10168@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >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. Agreed, but that's not an excuse to justify the way ".." behaves with symbolic links. I would achieve the same result by using sensible -I arguments to cpp (and no "../" in #include statements). I've never understood why -I switches are not as popular as they should. They're very useful. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
richard@aiai.ed.ac.uk (Richard Tobin) (11/22/89)
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. Well, that's a nice paradigm to preserve, but another one is that a directory should be the same however you got there. Sometimes you want one, sometimes the other. (Of course, this isn't a problem of symbolic links per se; hard links would have the same problem but making hard links to directories is "discouraged"). I think it's a bad idea for shells (or whatever) to treat ".." as something special. It would be better to use a new name ("..." perhaps?). -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
peter@ficc.uu.net (Peter da Silva) (11/23/89)
[ re: file systems treating .. as an operator rather than a link ] In article <10168@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > 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. This isn't a problem. "../foo/x.h" would work. It's the component *before* the ".." that gets eaten, not the one after it. Say you're in "/u/ark/bar", then "../foo/x.h" becomes "/u/ark/bar/../foo/x.h", which becomes "/u/ark/foo/x.h". The Amiga file system does this, by the way. I think it's more trouble than it's worth. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
peter@ficc.uu.net (Peter da Silva) (11/23/89)
While we're adding new syntax to the shell... Personally I think "..." should be a wildcard denoting a recursive search: echo .../*.c This should be equivalent to: echo `find . -name '*.c' -print` Prior art: VMS does it this way. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "Peter da Silva's (sp?) signature with the little drawing in it is probably OK" -- Jonathan Kamens <jik@Athena.MIT.EDU>
merlyn@iwarp.intel.com (Randal Schwartz) (11/28/89)
In article <12407@ulysses.homer.nj.att.com>, ekrell@hector (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. | | Besides, this is the only sensible interpreation of ".." on implementations | where ".." does not exist physically as a directory entry (which is | not required by POSIX). Well, let's take a look at that. Current unicies do not maintain a path to the current working directory... just a handle on the inode. Do you propose maintaining a real path throughout all chdir(2) calls? What if a portion of the path gets renamed? Does the path become invalid? (a new errno error: ECWDGONE == "The current directory is no longer valid".) Nope. ".." will probably mean what it means for a real long time. :-) Just another UNIX hacker, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
ekrell@hector.UUCP (Eduardo Krell) (11/29/89)
In article <5270@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes: >Do you propose maintaining a real path throughout all chdir(2) calls? I don't know what you mean by that. Is this a question about the concept or about a particular implementation of it? We implemented it in the namei cache, which holds an entry for the root directory and current working directory of all processes. It actually has entries for each path component, so /usr/foo/bar1 and /usr/foo/bar2 share the 2 entries for /usr and /usr/foo. >What if a portion of the path gets renamed? Does the path become >invalid? (a new errno error: ECWDGONE == "The current directory is no >longer valid".) That's not a problem with the above implementation. You just have to play with the pointers in the cache to make them point to the new component(s). >Nope. ".." will probably mean what it means for a real long time. :-) Maybe, but you'll have to find another excuse now. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com