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: <1858@munnari.oz>
Date: Tue, 13-Oct-87 18:26:29 EDT
Article-I.D.: munnari.1858
Posted: Tue Oct 13 18:26:29 1987
Date-Received: Fri, 16-Oct-87 22:35:40 EDT
References: <9721@brl-adm.ARPA> <1849@munnari.oz> <6555@brl-smoke.ARPA>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 68

In article <6555@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn) writes:
> In article <1849@munnari.oz> kre@munnari.oz (Robert Elz) writes:
> >"" is NOT ".", they are two totally different names (which happen to usually
> >be links to the same file).
> 
> Elz is usually right, but this time he isn't.  I've never seen a UNIX
> implementation where the empty string was an actual link.

Yes, sorry, I meant, and should have said, that "." is usually a link to the
current directory, which is represented by "".  "" is not a link itself
of course, its a method to access the kernels saved internal representation
of the current directory, where "." searches that directory for the name "."
and uses whatever that happens to be, which is usually the same thing.

> Under normal
> circumstances, there is no way for a normal user process to subvert the
> advertised meaning of ".".  (A privileged (UID==0) process can of course
> do anything at all, including completely mangling the filesystem or
> replacing the kernel with an alternative that looks nothing like UNIX.)

Yes, without doubt, using "." is correct in 99% of cases (100% if you
know that you're using a kernel that guarantees it, as its reported
that some HP kernels do).  However uid==0 does exist, and there are
occasions where processes need to be able to work in spite of what
the super-user might have done.

> >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 ...
> 
> Sorry, I don't see any "logical equivalence".  In fact, as you must
> know, many people are successfully using systems where "" doesn't work
> but "/" does access the root of the filesystem hierarchy.

I meant "logically equivalent" not "couldn't be otherwise".  To interpret
"/" correctly you must use the same reasoning as is used to interpret "".
That is "start at the root directory (kernel's internal idea of what that
happens to be) and then go nowhere".  Just as "" is "start at the processes
current working directory, and then go nowhere".

Obviously, kernels can implement whatever they like, their existance doesn't
imply logical consistency.

> The main
> argument was that the empty string is invisible when used as a component
> of a path; although "dir/" (with the null string after /) works fine,
> "/subdir" (with the null string before the slash) doesn't work right,
> whereas "./subdir" works fine.

Yes, this is a potential programming problem, programs do need to check
for "" and handle it differently.  Unfortunately, that's true of many
things, and outlawing them all isn't the way to fix this, education is.

I believe that "/" suffers the same problem in some implementations
doesn't it?  Adding "/subdir" after "/" doesn't always work.  Ie: what
is produced is "//subdir" which is fine in most unix's, but outlawed
in some others (or has a different meaning).  Again, using "/." the
alternative (usually correct) name for the root will fix this, producing
"/./subdir" which is (should be) always legal.  Programs just have to deal
with all these cases.  A "pathcat" C library function that would do the right
thing in all cases would be a useful addition.

I also thought that some kernels had outlawed "dir/" with the null string
there being treated much like that in "".  Silly, but if "" is going to
be illegal, then it is consistent to outlaw the other case as well.

kren