Various people have written, on the subject of "" paths,

> [...], which in turn leads me to wonder if the traditional BSD
> acceptance of "" was just a minor coding bug to begin with.

> If the traditional BSD implementation was a bug or accident, [...]?

> Actually, it seems likely that it was done to be more compatible with
> /bin/sh's treating "" as ".".  [in $PATH, where zero-length
> components are equivalent to . components]

> Well, at this point in time, allowing "" to be a valid pathname is
> rather silly, [...]

There actually is good reason for allowing "" to be a valid pathname,
referring to the current directory: it is a degenerate, zero-component,
case of a relative pathname.  Look at the code...the naïve
implementation of pathname walking would be something like

	if (first char is /) { cur = root; eat the /; } else { cur = cwd; }
	while (there's more pathname)
	{ if cur isn't a directory, error
	  look up next component relative to cur, set cur to result
	  eat next component (and following /, if any)
	}
	return cur

This needs minor tweaking to handle multiple consecutive slashes and to
error if trailing slashes are present but the thing isn't a directory;
if you want to use the same thing for file creation, you have to tweak
it more to handle a nonexistent last component.

My point is, if you hand "" to this simple code, returning cwd falls
out automatically.  If you want "" to do anything else, such as an
error, you have to special-case it; witness cgd's recent patch to
namei, which does exactly that - special-cases it.  I would say, thus,
that the onus should fall on whoever wants to justify special-casing
it.  (Core may feel that "because POSIX says so" is all the
justification they need, of course.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu