From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Python filesystem Message-ID: <20011129140311.K317@cackle.proxima.alt.za> References: <20011129074900.F317@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from John Murdie on Thu, Nov 29, 2001 at 10:08:30AM +0000 Date: Thu, 29 Nov 2001 14:03:11 +0200 Topicbox-Message-UUID: 2ca368cc-eaca-11e9-9e20-41e7f4b1d025 On Thu, Nov 29, 2001 at 10:08:30AM +0000, John Murdie wrote: > > And very, very, retro, and contrary to the Unix (and Plan 9) > `philosophy' of putting commonly-required facilities in (just) one > place. If you did the above, wouldn't you have to add all the non-CVS > facilities of a shell to CVS (and to everything else you turned into a > shell)? > A valid point, but one that may apply to shared objects too :-) :-) :-) My intention was to cause the shell to build a namespace with the necessary (and only the necessary) tools in place. Those that are unique to the shell would be built (in a funny sense) into the shell and "exported" (that's an interesting solution to the lack of private environment variables in rc - just don't add them to /env, which means serving /env within the shell, doesn't it?) into the namespace as appropriate. I'm kind of looking for seamlessness between the shell and the namespace and, for the sake of protection, limiting the namespace to specific instances of modules that may have been sanitised for the purpose. Or extended, for that matter. I like embedded languages and my limited efforts with the namespace library made me think on how best to combine embedding with the more practical aspects of a shell and the environment it provides. But it is just rambles, right now. ++L