Date: Fri, 3 Jul 1998 16:13:48 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <v04011723b1c2dd579a5c@[128.113.24.47]> In-Reply-To: <199807030416.VAA03798@antipodes.cdrom.com> References: Your message of "Thu, 02 Jul 1998 18:10:44 EDT." <v0401171bb1c1acb4f7a9@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04011723b1c2dd579a5c>