Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: A challenge to all true hackers: objects and types
Message-ID: <1993Mar27.080741.2438@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <JKH.93Mar20153113@whisker.lotus.ie> <ARNEJ.93Mar24113744@chanur.imf.unit.no> <JKH.93Mar25020256@whisker.lotus.ie>
Date: Sat, 27 Mar 93 08:07:41 GMT
Lines: 48
In article <JKH.93Mar25020256@whisker.lotus.ie> jkh@whisker.lotus.ie (Jordan K. Hubbard) writes:
>>I'm using apollo Domain/OS SR10.4 (newest version) every day. And I
>>don't agree AT ALL. Apollo's filesystems break too many programs,
>>including the bundled C compiler. (You can't compile any file that is
>
>This is not a generic object-store implementation problem, this is
>an apollo implementation problem.
>
>>I also think that variant links using environment variables is a BAD
>>idea. Do you realize this means that EVERY BLOODY program that sets
>>environment variables must be very cautious about how it is done, and
>
>I don't see this at all. There are already a number of environment
>variables that one shouldn't set, like PATH, TERM, LANG, etc. Why is
>this any different? That is a very silly argument against a feature
>that potentially buys you so much more.
Also, at least in a naieve implementation, the environment read to look
at the variable is inherited from the parent (being set into initial
shell environments by init (for rc.local, et al) or login (for user shells).
Only user subprocesses can access modified environment variables. For
instance, the idea of setting an environment variable within a process and
then having it effect the proceess itself is dependent upon extending the
size of the environment. An implementation based on the initial location
of the environment store wouldn't take changes into account within a
single process. Anything beyond that would require fixup of the location
of the table relative to it's initial location (the only place it can be
distinctly identified without a lot of work), or a seperate environment
pointer maintained in the u or proc struct (thus requiring system calls
for getenv/setenv).
Boiled down, this means that the link really can't be changed for the
program doing the changing; only for it's children... so you *DON'T*
need to take care in setting environment variables if the fear is that
it will impact the program setting them.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------