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"..