chris@mimsy.UUCP (Chris Torek) (11/04/87)
[Background: I claimed that */, a//b, and //x all have the zero-length string as a name component, and that SysV should therefore reject them. Those of you who are tired of this debate should stop reading this article now.] In article <1973@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: >Sorry to do this to you Chris, but that works just fine here. Actually, I had understood that to be the case. I was in fact cloaking a philosophical argument for "" => current directory. [implementation deleted] >... my understanding of the original bug was if the first `c' was >'\0', the current I-node, which was the current directory, since >c != '/'. That's why "" == . in the old world. Consider "/", where >the first character returned is '/', and after that, the next is '\0'. Yes, consider it well! >But '/' is still quite special ... And (philosophically speaking) I consider this a fault. The fewer special cases imbedded in a naming system, the better; *no* special cases is ideal. If you wish to have both relative and absolute naming, however, you must either provide two different name lookup routines (in which case a name is no longer simply a string, but rather a string and a selector) or add a special case. Unix uses the special case, and ultimately I must agree with this particular choice. Now given the special case that a leading separator `/' indicates an absolute path name, the proper (I claim) way to regard the name lookup is this: First peek at the first character. If it is `/', consume it, and begin at the root; otherwise begin at the current directory. From then on every `/' is always a separator. Traverse the file system by looking up every name component (including null components such as the one in a//b) and stop only when you run out of components or cannot find a component in the current directory as of the most recent separator. As it happens, the null name is not in fact stored in any directory. But this is an *implementation detail*: it is entirely unrelated to the apparent operation of the naming system. Like `.', the null name refers to the current directory as of the most recent separator. If you want to disallow null names, to be consistent you should (I claim) disallow them everywhere: If open("") returns ENOENT, it should do so only because the null name is not stored in the current directory. But since the null name is not stored in the root directory, open("/") should also return ENOENT. open("a//b") and open("x/") should likewise fail. *To be consistent, the null name must be nowhere or the null name must be everywhere.* Since most people agree that `/' suffices to name the root directory (`/.' being the next alternative), I say that the null name is everywhere, and open("") should begin at the current directory and find the null name and stop. System V's name lookup routine claims that the null name is everywhere *except* the current directory, and at that, only the first time it looks there! (open("./" succeeds and opens the current directory.) *This* is the behaviour to which I object. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jc@minya.UUCP (John Chambers) (11/08/87)
In article <9203@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > [Background: I claimed that */, a//b, and //x all have the > zero-length string as a name component, and that SysV should > therefore reject them. Those of you who are tired of this debate > should stop reading this article now.] > Yet another extension of the argument: A couple of days ago, I found myself with a new login id on a BSD machine which I needed to initialize to all the stuff that I'm used to using. Being lazy, I just copied stuff from my main host: rcp -r foo: . This worked just fine. Then it occurred to me that I had used the dreaded null file name. The "foo:" string is of course parsable into the host name "foo", a separator ':', and a directory name "". Since rcp prepends your home directory to anything not starting with '/', it acts just like you'd expect. I'm glad it did this sensibly, and didn't tell me that "" is an illegal pathname. There are too few hours in the day to waste them hassling with silly software that won't do such straightforward, unambiguous commands as the above because of someone's idea that null strings shouldn't exist. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)