/tmp... (null pathnames)

[BALDWIN]

> > 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