From owner-freebsd-hackers Fri Jul 3 13:09:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12393 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 13:09:58 -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 NAA12386 for ; Fri, 3 Jul 1998 13:09:56 -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 QAA54782 for ; Fri, 3 Jul 1998 16:09:56 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199807030416.VAA03798@antipodes.cdrom.com> References: Your message of "Thu, 02 Jul 1998 18:10:44 EDT." Date: Fri, 3 Jul 1998 16:13:48 -0400 To: hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:16 PM -0700 7/2/98, Mike Smith wrote: >> I think there would be less headaches all-around if symlinks did not >> key off environment variables, although I do think we'd want them to >> key off of something as simple to adjust as environment variables are. > > This expresses my opinion quite succinctly. Overloading the > environment space to also control variant links would be a Very > Bad Idea, simply because the risk of name collision is too high. > > Allowing links to indicate that they *should* be keyed off the > environment space, OTOH, isn't such a sin. eg: > > ${sysctl:hw.arch} and ${env:USER} Now that I've caught up on my sleep a bit, I do think something along these lines could be promising. I can't find Terry's earlier suggestion (even though I know I reread it just last night), but I think that what I want might not be all that much different from what he suggested. Let's say there are three namespaces (just to pick a number): sys session process (I know those aren't the names Terry used, but since I can't find his message I'm making up new names. I'm sure we need better names than what I'm using here...). "Sys" variables are system-wide values. Only root can change them, to everyone else they are read-only. If root changes does them, the value changes for all users on that system. These might be things like "platform", "oslevel", and "arch". "Session" variables can be changed by a user. If the user changes them, the change effects only that user. It will effect all processes related to the current "login session" of that user (if that is doable...). Ie, if I have four xterm's up, and I change the value in one xterm, it is also changed in all other xterms. However, if I have done a "telnet localhost", then that session (the one on the other side of the telnet) is not effected. I expect that the login process itself would probably create the initial values for several session-level variables. "process" variables are just standard environment variables. If you change them in one xterm, other xterms are not effected. It just effects that process, and all processes which that process subsequently execs. - - - If I remember right, that isn't too much of a change from what Terry had suggested. What I think we need to change is the rules for name resolution. Where Terry suggested (in a message that I *can* still find...): My preference?: I. Look in my env II. Look in the process group leader's env III. Look in init's env IV. replace them with "" (zero length string, just as sh does). I would suggest that: ${sys:somevar} always resolves to the session-level variable. the user has no way to dynamically change the target of this link. ${session:somevar} uses the session-level variable, if it exists. If it doesn't exist in the seesion-level, look for a system-level variable of the same name. ${process:somevar} or ${env:somevar} uses the environment-level variable, if it exists. Otherwise, try for a session-level variable of the same name, and if that doesn't exist then go with the system-level variable. I'm not sure what should be done in cases where the variable is not found in any namespaces that are appropriate to search for it. I could probably make up good reasons for any one of: a) replace ${blah:somevar} with "" b) replace ${blah:somevar} with "somevar" (ie, if there is no variable of a given name, then substitute with the name of the variable instead of it's value). c) leave ${blah:somevar} as ${blah:somevar} (ie, act as if there is no such thing as variant symlinks, and just look for a real filename which includes those characters in it). I don't know if the above is the ideal mix, but I think it manages to be safer than earlier suggestions, and yet keeps all the flexibility one *might* want to have for variant symbolic links. I do have a feeling there should be something different than the "session" level as I described it, perhaps replacing that with two other levels. I don't know what I'd want to call those levels or how to describe them, but I just have a vague feeling that "session level" isn't quite right (it seems to me I'm trying to solve more than one issue with that one level...). --- 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