Date: Thu, 2 Jul 1998 18:50:46 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <v0401171cb1c1b6683f8e@[128.113.24.47]> In-Reply-To: <2433.899394653@time.cdrom.com> References: 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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0401171cb1c1b6683f8e>