Date: Fri, 3 Jul 1998 12:02:04 -0400 (EDT) From: Thomas David Rivers <rivers@dignus.com> To: drosih@rpi.edu, jkh@time.cdrom.com Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807031602.MAA18581@lakes.dignus.com> In-Reply-To: <v0401171ab1c15255bb5b@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
> > At 6:36 PM -0700 7/1/98, Jordan K. Hubbard wrote: > >> My initial reaction is that I wouldn't want links to depend on values > >> in environment variables. If I setup some "clean environment" for a > >> program I'm exec-ing, I'm not going to think to copy values which are > >> important for these links to work. > > > > If you have ever used Apollo's Domain/OS, the advantages of having > > synlink behavior be configurable by something as dynamic as the user's > > environment become very quickly apparent. :) > > There's a difference between "being dynamically configurable" and > "being part of a namespace which users, scripts, and programs are > already clobbering on a regular basis with no current need to worry > what that might do to filesystem access". > > 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. > We'll still be getting programs from many other sources which will > blindly manipulate the standard user environment, and which will > not be worried about what that might do to file system access. Yes - I like that distinction! > > I would be a little more specific here on what I'd like to see for > that, but I haven't quite settled on what that would be... In some > sense I'd like a session-level database of keys/values, such that I > could type in something in one xterm, and have that effect all active > applications (or maybe just all applications which *start* after I > enter the command -- even if they are not started from that xterm > window). On the other hand, I have a sneaking suspicion that isn't > quite what I want either... Let's explore this a little more... [I *really* like the idea of a separate name space.] First, having it separate might make this easier to implement (not sure about that.) Also, you'd want the environment inherited just as env is today (child processes shouldn't "loose" links just because they are children.) You'd want command-line interfaces for listing, defining, altering the names&values specified in this space. Now, it comes down to what "magic" are you going to use in the symlink string to denote that the space should be queried... - Dave Rivers - 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?199807031602.MAA18581>