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>