From owner-freebsd-hackers Thu Jul 2 08:51:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14875 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:51:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14818 for ; Thu, 2 Jul 1998 08:51:42 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id IAA02437; Thu, 2 Jul 1998 08:50:53 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Garance A Drosihn cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 11:29:51 EDT." Date: Thu, 02 Jul 1998 08:50:53 -0700 Message-ID: <2433.899394653@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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