Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!kre
From: kre@munnari.oz (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: /bin/test and stat(2)
Message-ID: <1849@munnari.oz>
Date: Sat, 10-Oct-87 12:12:22 EDT
Article-I.D.: munnari.1849
Posted: Sat Oct 10 12:12:22 1987
Date-Received: Mon, 12-Oct-87 06:16:20 EDT
References: <9721@brl-adm.ARPA>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 72

In article <9721@brl-adm.ARPA>, franco@MIKEY.BBN.COM (Frank A. Lonigro) writes:
> Everyone has commented on the fact that stat("", &stbuf) (stat of a zero
> length string) defaults to stat of (DOT) the current directory.

Then "everyone" is wrong (not that I think that is really what "everyone"
said in the first place).

"" is NOT ".", they are two totally different names (which happen to usually
be links to the same file).

"" is the ONLY totally reliable way for a process to access its current
directory, "." searches the current directory file the name "." and
normally finds an inode which is usually the current directory.  But
this is not guaranteed.

In some kernels, the vendor has decided to hard wire in the "." -> ""
mapping, so that it can't be changed.  That's fine, changing the meaning
of "." is not something that intelligent people do (which is probably why
I do it from time to time).  These systems are typically not really unix.

Some kernels have made the name "" illegal.  This was a silly decision,
as now there's no one portable way to access the current directory,
however it is "ok" if these kernels are also kernels where "." is wired
in, as "." then provides a guaranteed way to access the current directory.

Unfortunately, there are kernels which have prohibited "", and yet which
haven't wired in ".".  In these kernels (including one quite famous and
widely distributed version) there is no guaranteed way for a process to
access the current directory.

> 	1)  This is not documented anywhere, BSD4.*, SUN OS, ULTRIX , etc...

Not true.  Its quite explicitly stated in the Ritchie & Thompson
CACM paper, "The Unix Time-Sharing System", CACM, July 1974, pp 365-375.
This been updated, and reprinted, with the documentation of every variety
of the unix system that I've ever seen (there are probably a few that don't
include it (the vendor should be bankrupted) BSD and Sun OS aren't in that
category, I very much doubt that Ultrix is either).

For anyone who hasn't bothered to read this document, I advise you to
suspend all activities related to unix, and go and read it now.  It
should be the first document all new unix programmers (including shell
programmers) read.  All users should be encouraged to read it.

I will quote one sentence ...

	As another limiting case, the null file name refers
	to the current directory.

(The other limiting case is the name "/").

Logically, to prohibit "" as a name, one would also have to prohibit "/"
as a name, since they are logically equivalent.  "/." would be required
to reference the root (which  of course, isn't really necessarily the
root in any case).

> 	I guess maybe I'm supposed to know about the namei() quirk.

It is not a "quirk" regardless of what some people have claimed, its
a deliberate, and necessary, attribute of the unix file naming scheme.
However yes, you *are* supposed to know about the name "" (if you didn't
know it already, it should be obvious from a few minutes thought).

> 	2)  Programs like 'ls', 'cd', 'chmod', 'test', 'rmdir', etc....
> 	have all been coded to rely on this default

Nonsense.  Your examples merely show that none of those commands has
been deliberately coded to look for "" as a special case, and do
something different (and wrong) with it.  'test -d ""' (the original
question) *should* return true, as "" *is* a directory.

kre