Date: Thu, 02 Jul 1998 18:02:06 -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: <5406.899427726@time.cdrom.com> In-Reply-To: Your message of "Thu, 02 Jul 1998 18:50:46 EDT." <v0401171cb1c1b6683f8e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 But that's NOT what I was arguing for - that was merely a convenient example. I'm specifically arguing for being able to exploit an application's *existing* use of environment variables and NOT having to think "well gee, I guess a username is one thing we should make a magic variable for, and maybe the uid and pid, and ..." That somehow assumes that the designers are going to know what all the useful variables are going to be in advance, something which Unix itself has shown that they plainly don't. Users in the field are always going to think up even more odd-ball uses of the mechanism than the designers ever thought of. > 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 You're somehow confusing the user for the application writer here. When you say "you are going to use that", what you're really saying is the _user_ is going to use that as a convenient hook only after determining that it *is* a convenient hook. If it's not entirely appropriate then the user is going to have to either figure out another more effective one OR they're going to have to give up on the idea of customizing that application's behavior completely behind its back. Sometimes that works, sometimes it doesn't. In any case, this argument is also somewhat moot since neither of us is actually doing the work of IMPLEMENTING this baby and it's the implementor who is always going to have the final say as to how it works anyway. :-) - 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?5406.899427726>