mike@whuxl.UUCP (BALDWIN) (10/26/85)
> > A null path component already has a meaning (same as "."). > Well, yes, more-or-less; "the null file name refers to the current > directory" [The UNIX Time-Sharing System], and repeated slashes are ignored, > but (a) is this anything but a kludge so that "/" works? and (b) apart from > "/", has anyone ever used this facility in real-life? > > V7 (but not some other systems) even allows "fred///" as a synonym > for "fred" (an ordinary file); I can see no reason why this, and "///tmp//" > and so on, should not be errors. These are certainly not kludges, but degenerate cases that fall out of the namei code. First, you have to start at some directory, so if the path starts with / you start at root, else the current dir. A: Now, skip slashes. If there's nothing left, return. Else make sure current component is a dir, and then gather next component from the path until / and search and reset the current component, then go back to A. This is the easiest way to parse pathnames, and "" == curdir and allowing trailing slashes both fall out. But now SV says "" is an error, and 4.2BSD doesn't allow trailing slashes! Very strange. As an answer to (b), it's a way of getting to the current dir without needing a "." entry, like if you're in a directory that has been rmdir'd, you can still type ls '' (big whoop). Also, it is faster than using ".", because it doesn't have to access the directory at all, it just sets the ptr and returns; using "." it has to read the dir to find the "." entry. One problem with "" though: it breaks the nice rule that dir/file always refers to a file in that dir. If dir=="", you get /file, not ./file (oops). But none of this really matters anyway. -- Michael Baldwin {at&t}!whuxl!mike
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/09/85)
In article <742@whuxl.UUCP> mike@whuxl.UUCP (BALDWIN) writes: [Attributions not included...] >> Well, yes, more-or-less; "the null file name refers to the current >> directory" [The UNIX Time-Sharing System], and repeated slashes are ignored, >> but (a) is this anything but a kludge so that "/" works? and (b) apart from >> "/", has anyone ever used this facility in real-life? >> >> V7 (but not some other systems) even allows "fred///" as a synonym >> for "fred" (an ordinary file); I can see no reason why this, and "///tmp//" >> and so on, should not be errors. [And Baldwin on pathnames ...] This is an aside from the main discussion. A lot of this confusion is generated by the fact that almost everybody teaches that, e.g., in a name like "/usr/bin/glumph", there are directories (nodes) named "usr" and "bin", and a file named "glumph". This is exactly wrong. Shocked? Surprised? Don't be. If those were their names, why can we have links to them named "." or "glomph"? (And remember how hard it was the last time you tried to explain links as alternate names to somebody?) I'm not going to say that the following is easier to understand, or the best way to explain things to people. It just happens to be right. In the name "/usr/bin/glumph", each file or directory (node) is named "/" or "". That's all. It's the connection ("link") between one and the next that is named "usr" or "bin" or "glumph". The picture (attempted later below) that labels nodes with these names should always label links with these names! But, this is why multiple "/"s mean the same as one (or none, where appropriate). I just said they were "names", but they are actually separators for the real names, the names of the links. And if there is nothing between them, then they reference the null link "", which goes nowhere (hence "" is equivalent in some systems to "."). Here goes the attempt at a pretty picture: _(/)_ etc_/ | \_bin _/ | \_ _/ usr | \_ (/) _(/)_ (/) _/ | \_ adm_/ | \_bin _/ lib | \_ (/) (/)___ (/)_ \___ \_ glomph \___ \_glumph \___\_ () OK, Picasso I'm not. Next time I'll send along a rasterized image. ;-) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
mike@whuxl.UUCP (BALDWIN) (11/12/85)
> In the name "/usr/bin/glumph", each file or directory (node) is > named "/" or "". That's all. It's the connection ("link") > between one and the next that is named "usr" or "bin" or "glumph". > The picture (attempted later below) that labels nodes with these > names should always label links with these names! But, this is > why multiple "/"s mean the same as one (or none, where appropriate). > I just said they were "names", but they are actually separators for > the real names, the names of the links. And if there is nothing > between them, then they reference the null link "", which goes > nowhere (hence "" is equivalent in some systems to "."). Um sorry, but you're wrong. The kernel does *not* treat a///b as a/""/""/b; if you look in nami.c, there a loop that skips multiple slashes. So /// == / is not because of "" magic, it's just what the code does. Directories being named "/" or "" just doesn't wash. If you're talking about inodes, dirs don't have any names at all. This is how you *really* get to ///usr///bin///glumph///: path starts with / so start in root dir [skip /'s] get inode for entry named "usr" [skip /'s] make sure it's a dir, get inode for entry named "bin" [skip /'s] make sure it's a dir, get inode for entry named "glumph" [skip /'s] no more path, so return Anyway, all I really wanted to say was that a///b has nothing to do with null names. -- Michael Baldwin {at&t}!whuxl!mike
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/17/85)
In article <800@whuxl.UUCP> mike@whuxl.UUCP (BALDWIN) writes: >> In the name "/usr/bin/glumph", each file or directory (node) is >> named "/" or "". That's all. It's the connection ("link") >> between one and the next that is named "usr" or "bin" or "glumph". >> The picture (attempted later below) that labels nodes with these >> names should always label links with these names! But, this is >> why multiple "/"s mean the same as one (or none, where appropriate). >> I just said they were "names", but they are actually separators for >> the real names, the names of the links. And if there is nothing >> between them, then they reference the null link "", which goes >> nowhere (hence "" is equivalent in some systems to "."). > >Um sorry, but you're wrong. The kernel does *not* treat a///b as >a/""/""/b; if you look in nami.c, there a loop that skips multiple >slashes. So /// == / is not because of "" magic, it's just what >the code does. Directories being named "/" or "" just doesn't wash. Think about it. a///b is not "a"/""/""/"b", it is a///b. Have we said enough nothing? To be more explicit than above, the null-named link, which is that link whose name is between the following two double-quotes: "", does not change the current inode at all. (This is different from the link named ".", which changes inodes to the inode on the other side of that link, which we all hope is the same as the inode we started from.) Thus, the file name between the following two double quotes: "", if not explicitly disallowed, refers to the current directory. The file name between the slashes in the path name between the following double-quotes: "a///b" is the same file name as the file name between the following double-quotes: "". (Are you as tired of all this as I am?) The code quoted by Baldwin merely implements what I had been trying to describe. >Anyway, all I really wanted to say was that a///b has nothing to >do with null names. Suit yourself. Opinions are free. And it's not all that important. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}