From owner-freebsd-hackers Thu Jul 2 15:47:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24788 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 15:47:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24774 for ; Thu, 2 Jul 1998 15:47:00 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id SAA37432; Thu, 2 Jul 1998 18:46:55 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <2433.899394653@time.cdrom.com> References: Your message of "Thu, 02 Jul 1998 11:29:51 EDT." Date: Thu, 2 Jul 1998 18:50:46 -0400 To: "Jordan K. Hubbard" From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:50 AM -0700 7/2/98, Jordan K. Hubbard wrote: >> 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. [...skipping along ...] > 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. Let me take this specific example, and argue against symlinks that are based on environment variables for multiple reasons. (at least as far as I understand the issues in the example) What you're arguing for here is a symlink based on the unix userid, which certainly is a good candidate for a system-wide variable. All the example shows is that the system should create such a variable for use in symlinks. The example does not prove that the value is "required" to be an environment variable. Also, given the specific key of "USER", that is a value that shells or something else in the login process often sets. As it happens, I once wrote a 'install' script which wrote that very value out to a log file (just to track who was installing what, when...), and I later found that in some makefiles that didn't work. Why? Because the makefile itself defined "USER" to mean something else (the list of user-level programs, as opposed to administrator-type programs). As this shows, most "nice, pretty and convenient" names for use in symlinks are going to be words which are just as "nice, pretty and convenient" for everything else which plays around with the user environment. However, let's say the program itself happens to set an environment variable called "PROGUSER", and you're going to use that. You do not depend on the user themselves remembering to set this variable (which is good (*)), because you know the program itself sets the value before it reads the configuration file. The user runs the program, the program goes to the desired config file, and it happens that the config file isn't exactly what the user wants. They quit the program, and edit the config file via the symlink (because they know that's what *program* opens), and not the target of the symlink. But when they go to do that, the PROGUSER variable is not set, so they do *not* get the same filename that the program itself is using. Just imagine how many times they'll swear at the program because it isn't being effected by changes to it's config file, before they realize that they're editting a different file (especially for the users who did not actually create the symlink which references the environment variable). (*) - Let's say the program itself does not set the environment variable. This now means you won't get the expected behavior out of the program unless the user remembers to sent the environment variable. To that I say "Ick". To avoid that, you write a wrapper around the program to set the environment variable before the program starts up, and point the user at that wrapper instead of the real program. To the user, this wrapper is now the real program, and you're right back to where you were (in the previous paragraph) with using a variable that the program itself sets. Certainly it is an attractive idea to base symlinks on environment variables, but maybe we should ask ourselves how hard it would be to implement a "nice clean private namespace somewhere". I think we'll be happier with the separate namespace, something which isn't disrupted as readily and as often as the user environment. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message