Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!homxb!whuts!mtune!codas!novavax!murphy!dave
From: dave@murphy.UUCP (Dave Cornutt)
Newsgroups: comp.unix.wizards
Subject: Re: /bin/test and stat(2)
Message-ID: <653@murphy.UUCP>
Date: Tue, 20-Oct-87 18:41:15 EDT
Article-I.D.: murphy.653
Posted: Tue Oct 20 18:41:15 1987
Date-Received: Fri, 23-Oct-87 01:27:39 EDT
References: <9479@brl-adm.ARPA> <4779@ncoast.UUCP> <8898@mimsy.UUCP>
Organization: Gould CSD, Fort Lauderdale, FL
Lines: 50
Summary: Maybe, but it can be damned inconvenient

In article <8898@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <4779@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:
> >... Some, but most definitely NOT all, versions of Unix explicitly
> >check for a null path in namei() and return an error (ENOENT, or
> >perhaps EINVAL).  All others have the bug; since it's not exactly
> >crippling, it's not considered a high priority to fix it, so it stays.
> 
> It is also not considered a bug (at least by some), just as the
> null set is considered a set (at least by some), and zero sized
> arrays are considered not unreasonable (at least by some [An error?
> Probably.  But what if . . . ?]).

I rarely find myself in the position of disagreeing with Chris, but I
remain unconvinced on this one.  Others, such as John Chambers, have
also expressed support for the principle that the null string should
be a valid filename.  Indeed, it does state in the 4.3BSD manuals
that "" refers to the current directory.  Trouble is, it also refers to
the root directory, depending on the context you use it in.  Suppose
you write something that will take a directory name and open a file
"foo" in it.  I'd probably do this by taking the directory name and
concatanating "/foo" to it, so if the name was "xyz", I'd get 
"xyz/foo", and if the directory was ".", I'd get "./foo", both
of which would access the desired file.  Trouble is, if the directory
was "", it wouldn't work; although "" might be a perfectly valid
directory, appending "/foo" to it would produce a reference to the
root directory, which is certainly not was intended.  If I thought
that someone might actually want to do this, I'd have to stick in
a special check for "" and substitute something else.  So, where
do you want the special check to go: in every program that might
be given "" as a directory name, or in the kernel where it can be
eliminated as a legal filename and save everyone a lot of headaches?

As for "." not existing on some systems: the use of this to mean the
current directory is so common in Unix systems nowdays (far more than
"", which I'll bet many people that read this group weren't aware of
before this discussion came up) that if I ran into a system where it
wasn't implemented somehow, either as an actual file name or as a
magic name in the kernel, I would complain to the vendor and tell
them that their implementation is incomplete.
---
"I dare you to play this record" -- Ebn-Ozn

Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP:  ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt
 or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcornutt@gswd-vms.arpa

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."