larryr@cbnewsd.ATT.COM (lawrence.m.ruane) (06/16/89)
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. This idea can be extended. If the `root' of my LAN is mounted on "/n", and the `root' of my company is mounted on "/c", and the `root' of the world is mounted on "/w", then I can get to my home directory (from my home machine) with any of the names: /usr/larryr /n/ihlpa/usr/larryr /c/ih/ihlpa/usr/larryr /w/att/ih/ihlpa/usr/larryr In fact, if multiple mounts on the same mount point were possible, the idea could be extended in the other direction too. My home directory could be "/", and the root of my machine could be "/m". Then, I could get to my home directory with any of these names: / /m/usr/larryr /n/ihlpa/usr/larryr /c/ih/ihlpa/usr/larryr /w/att/ih/ihlpa/usr/larryr Extending the example given in "the Hideous Name" (presented at one of the 1985 Usenix conferences, I think), I can see which machines in the world I have an account on (including my own) with grep larryr /w/*/*/*/etc/passwd Larry Ruane
grr@cbmvax.UUCP (George Robbins) (06/17/89)
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)
andrew@frip.WV.TEK.COM (Andrew Klossner) (06/19/89)
[]
"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."
No, innocent programs get hung up too. For example, this shell script
fragment:
cp input_file $HOME/tmp_file
will, if run by root (with $HOME="/"), expand into:
cp input_file //tmp_file
and the kernel network code goes off in search of machine "tmp_file". We
encounter this quite a bit, and have placed several hacks to work
around it (such as setting root's HOME to "/."), but it still bites the
unwary.
-=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]peter@ficc.uu.net (Peter da Silva) (06/21/89)
Why is 'root's home '/'? Historical reasons? Because it's more likely that '/' will exist after a disaster so root can still log in? I've often thought that '/etc' would be a more logical 'home' for root. I certainly spend more of my 'root' time there. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
clive@ixi.UUCP (Clive Feather) (06/21/89)
In article <3620@orca.WV.TEK.COM> andrew@frip.WV.TEK.COM (Andrew Klossner) writes: } "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." } >No, innocent programs get hung up too. For example, this shell script }fragment: } } cp input_file $HOME/tmp_file > }will, if run by root (with $HOME="/"), expand into: > } cp input_file //tmp_file } }and the kernel network code goes off in search of machine "tmp_file". Posix says that leading // is implementation defined, but all other cases of multiple slashes are equivalent to a single slash. The Rationale then tells you to concatenate using two slashes: cp input_file $HOME//tmp_file This will work unless $HOME=// (a very unlikely case). -- Clive D.W. Feather IXI Limited clive@ixi.uucp ...!uunet!ukc!ixi!clive (riskier)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (07/22/89)
Many people has mentioned their favorite scheme of identifying hosts with a filename. /.., //, @host, host:/, etc. I think it should be left up to each site to organize this the way they want within the standard unix file system. We are using Sun's automount here, and it solves all of these types of problems. In fact, it gives us more flexibility, with just a small amount of administrative effort. As an example, we currently have the following conventions: /home/machine - Users home directories, mounted read/write, setuid disabled hard mounts, points to machine:/home/machine usually, but not always. /crd/machine - public stuff, mounted read only (by default), soft mounts. /net/machine - read only, soft mount, no setuid. Points to machine:/ used to get access anywhere permissions allow. There are other schemes we could have done, like /home/user - for someone's home directory, where ever it is. or /project/whatever - current location of a project /source - points to source for the machine you are logged onto. /common/bin - points to one of a set of common redundant public binaries. Setuid programs are allowed here. The point is, I don't want a single filename to point to machine:/ I want to set up a flexible scheme that allows me to customize our file name space, controlling variations in mounting, permissions, etc. Having a single name mapping (pointing to machine:/) is not adequate. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP