Date: Sun, 13 Jun 1999 17:28:47 -0700 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: "Chuck Youse" <cyouse@cybersites.com> Cc: "Marc Ramirez" <mrami@gbtb.com>, hackers@FreeBSD.ORG Subject: Variant symlinks [was Re: symlink question] Message-ID: <53369.929320127@zippy.cdrom.com> In-Reply-To: Your message of "Sun, 13 Jun 1999 20:05:23 EDT." <003001beb5f9$9b10b480$65e684ce@sloth.yousehouse.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Forgive my ignorance, but what exactly is meant by a "variant link", and
> what might one be used for?
Gee, it's refreshing to see someone other than myself bringing this
subject up. :)
Variant symlinks, which many of us fell in love with back in our Apollo
days, are essentially just symlinks with a level of variable expansion
added in. E.g. back on the Apollo, you could do thinks like this:
ln -s /usr/bin '/binaries/${ARCH}/bin'
And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin
depending on the user's $ARCH environment variable, ostensibly set by
default by the shell but also user-modifiable with setenv. Many other
things involving architecture, timezone or natural language neutrality
are also obviously possible with this mechanism, this is just one
example.
The problem with doing this under FreeBSD always arises when one
contemplates getting at the user's environment from the context of
namei() - Apollo was able to see this problem coming and plan for it
in advance, Unix did not and it's not quite so trivially contemplated
here. ;)
That, in turn, generally leads folks away from the environment and
into a more sysctl-based (or other analogous) mechanism for setting
symlink variables, that stage generally bogging down over the question
of implementing user, group and system-wide variable spaces when all
the VMS people jump into the discussion and make a good case for this.
The current sysctl implementation assumes just one system-wide
variable space.
Good luck on this iteration, guys - that's all I can say. :-)
It's a worthy feature, doing it truly correctly is simply
hard.
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53369.929320127>