Date: 15 Jun 1999 11:58:25 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: dscheidt@enteract.com (David Scheidt) Cc: hackers@freebsd.org Subject: Re: symlink question Message-ID: <86aeu1on66.fsf@not.demophon.com> In-Reply-To: dscheidt@enteract.com's message of "15 Jun 1999 09:58:21 %2B0300" References: <2743.929428404@zippy.cdrom.com> <Pine.NEB.3.96.990615014431.86791A-100000@shell-1.enteract.com>
next in thread | previous in thread | raw e-mail | index | archive | help
dscheidt@enteract.com (David Scheidt) writes:
> First try: Suppose foo depends on /usr/local/etc/foo.conf.
> /usr/local/etc is a link to /usr/local/${ARCH}/etc. User does
> export $ARCH=../../home/user, so /usr/local/etc/foo.conf is now in
> their home directory. Depending on how poorly written foo is
Eww, I don't like the idea of using environment variables this way.
The kernel shouldn't rely on them, they are a userland thing except
during execve. Environment variables aren't even visible to the
kernel in the process that sets them.
Variant symlinks don't need to be controlled through environment
variables. If there is a specific use in mind for variant symlinks,
the mechanism for configuring them should be chosen with consideration
for that. (Even if variant symlinks could be environment variables,
there should be ones that are based on some "hard-wired" info and
system-wide variant symlinks should only use environment variables
when user-modifiability is specifically desirable. Your example is
obviously a case of improper use.)
If there is no specific use in mind for variant symlinks, other than
to have fun magic thingies around to play with that *can* be used for
such-and-such, then implementing them is not a particularly good idea.
For example, Lites had variant symlinks with keywords that were
internally resolved to the architecture/system name or the name of the
system being emulated.
For Lites, this was much better than something equivalent to FreeBSD's
/compat hacks, because emulated systems were "equal", and the root
partition could be shared with the real system. For FreeBSD, the
current approach is probably better, because emulated systems are
optional exceptions.
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?86aeu1on66.fsf>