Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.unix.wizards
Subject: Re: network filenames
Keywords: network transparent filesystem
Message-ID: <7095@cbmvax.UUCP>
Date: 16 Jun 89 20:18:25 GMT
References: <1989Jun6.000120.14888@eci386.uucp> <216@cbnewsd.ATT.COM>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 36

In article <216@cbnewsd.ATT.COM> larryr@cbnewsd.ATT.COM (lawrence.m.ruane,ih,) writes:
> In article <1989Jun6.000120.14888@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes:
> >I see '//' as a huge kludge, 'cause it special-cases the meaning
> 
> A beautiful idea is to associate names with meanings by *convention*.
> For example, while everyone (people and programs) knows the 
> conventional meaning of of the name "/dev/tty", this string 
> appears nowhere in the kernel.
> 
> That's why I like the "/n/host" syntax.  Such names require no 
> special detection by the kernel, as "//host" does.

But there is always the using a single letter to stand of an idea or
a word.  It's pretty convienient, it's not vary obvious that what you
are saying is 'get me out of my local context into a broader network
context'.  Almost as bad 6 characters name . 3 character extension.

If find // to be both concise and from the *users* point of view
quite indicative of "something special".  It seems that only "wizards"
get hung up on the point that is normally semantically equivalent to /
in file names.

The /.. is quite elegant and only breaks the notion that the root directory
is it's own parent.  From the users point of view, however, it's just a
string of ugly magic characters.

Personally, while I'd like to see a uniform convention, I'm not sure
its something to get excited about.  I only mount a few remote filesystems
and have them appear to be in the root directory.  Not surprisingly
/machine, //machine, /../machine all work and one could make /n work also.
If there be bugs with mounting remote filesystems on root, I'd prefer to
see those problems addressed...
-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)