Date: Thu, 02 Jul 1998 08:50:53 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <2433.899394653@time.cdrom.com> In-Reply-To: Your message of "Thu, 02 Jul 1998 11:29:51 EDT." <v0401171ab1c15255bb5b@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
> I should note that I do want something that's readily configurable.
> I just don't think the user-environment is the best place to hold that.
I'm not arguing that the user environment is a poor second choice when
compared to a nice, clean private namespace somewhere (or even just
sysctl(3), though I suspect you'd want something more dynamic than
that).
What I guess I'm trying to say is that my personal definition of
"readily configurable" for most of the existing tools more or less
_requires_ this behavior. If you know, for example, that an existing
application is using its environment as a configuration database of
sorts (not an uncommon situation), you can take advantage of that
knowledge in various interesting ways. Let's say, for example, that
you had a program which saved its configuration options into one file
and you really wanted that to be a user-specific file because several
people were sharing the application now. Let's also say that other
docs and general poking around revealed that the invoking user's name
was stashed in an environment variable called USER - you can now
exploit that knowledge by replacing the configuration file with
a v-symlink of ``/tmp/dotfiles/${USER}.thisapp.conf'' or something.
As sef has already noted, however, there are still problems with the
"let's make it totally transparent" approach. In storing a bunch of
v-symlinks in a tar file, for example, you might want to have those
v-symlinks left unexpanded so that you can copy them from one place to
another with tar/pax/whatever without destroying them. I haven't been
able to think of any really clean solutions to this one yet.
- 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?2433.899394653>