Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: symbolic links are a botch Message-ID: <6114@brl-smoke.ARPA> Date: Sun, 12-Jul-87 18:02:51 EDT Article-I.D.: brl-smok.6114 Posted: Sun Jul 12 18:02:51 1987 Date-Received: Mon, 13-Jul-87 05:09:52 EDT References: <2629@ulysses.homer.nj.att.com> <390@murphy.UUCP> <898@rtech.UUCP> <8738@tekecs.TEK.COM> <241@nuchat.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 60 In article <241@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >... Image links are a horse of a different color, And I'd like >to hear from those in whom my remarks strike a responsive chord. One way to implement a similar facility is to support "union" mounting of directories (or more generally, named objects) on each other (as opposed to the "replacement" mounting we now have). This idea is not original with me, but I don't know if the originator wants to get involved in this discussion at this time. I won't explain how to implement this, since it's just straightforward exploitation of data structures. However, I do want to mention some of the things I've been thinking since I first heard this idea: Unioned directories could be used in several ways to accomplish useful things currently done via other approaches on conventional UNIX systems. For example, one could set up his "command directory" to contain the union of the desired real ones, replacing the PATH environment variable and making the shell's job simpler (since it would just open a command in a known place, rather than searching for it). As mentioned by Steve, this could also be used in a Yost-like SCCS replacement. "cc" could look in the user's "library directory" for all -l options. Many other similar uses come to mind. The order of precedence when two unioned directories contain entries having the same name would be determined by the order in which the directories were unioned. (In the PATH example, one would arrange for the directory that would normally be leftmost in the PATH to be the one with priority in the union.) There are uses for both union-with- highest-priority and union-with-lowest-priority, so both should be supported (I would do this at the system call level by using an extra argument analogous to the mount() syscall's R/W flag). The originator of this idea seemed to think that there was a natural choice to make here, but I think that the "natural" choice depends on the intended use and what is natural for setting up the equivalent of $PATH is not necessarily natural for other uses, e.g. pushing and popping environments. So far I've managed to identify the following union- mount functions that I think are necessary: Create a name with nothing associated with it (an empty union) Append an object to the union (with low precedence of its members) Prepend ditto (high precedence) Remove one object from the union "tail" (lowest precedence object) Remove one object from the "head" (highest precedence) Destroy the name/union (may require that it be empty to succeed) Optional but probably useful: Remove all objects from the union (leaving an empty union) Remove all objects but one from the head Ditto from the tail Report union tail object name (or other ID) Ditto head object name Ditto all unioned object names (this is difficult to design; perhaps it should just report the nth object from the head or tail.) Many of these functions, perhaps all, could be combined into a single interface. For example, head-relative might be a positive argument and tail-relative negative. That's enough for now. I'll let you guys think about this for a while. I think it's a marvelous idea if it can be made to work (and I think it can). However, the result would not be properly called "UNIX"..