/tmp... (null pathnames)

[Joseph S. D. Yao]

In article <800 at whuxl.UUCP> mike at 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 at seismo.{CSS.GOV,ARPA,UUCP}