Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/mod.std.unix.v4/text0004.txt

Internet Message Format | 1987-06-30 | 3.7 KB

Date: Wed, 4 Dec 85 21:31:45 cst
From: allegra!jpl (John P. Linderman)

Geoff Kuenning ({hplabs,ihnp4}!trwrb!desint!geoff) raises some
interesting points.

> Have you every typed "show *" on VMS (or whatever the syntax is;  I'm
> glad to say I've forgotten)?  [Nope. jpl] You will get a list of literally
> *hundreds* of environment variables, most of which are absolutely
> necessary for the system to work properly.  The result is you can never
> find anything.
>
> It is *not* a good idea to cavalierly add variables to the environment.

Perhaps my posting was unclear.  The environment variable was to be used
to *override* values that were always present in limit.h or /etc/limits.
It is not necessary to use environment variables if you are willing to
live with the defaults.

> In the first place, it increases the cost of forking *and* exec-ing,

I have certainly heard this stated often enough, but I have never
really observed it.  Perhaps I run on larger machines, or have a
smaller environment.  If we are talking hundredths of a second, it isn't
worth discussing.  If we are talking seconds, I think your fork
and exec are broken.  Anybody have hard documentation on the effect
of environment size?

> in the second place every program has to provide for the variable, and

I draw a blank on this one.  The putative library routine that looks
up the values also handles the environment variable.  No other source
code cares.  This is in sharp distinction to alternatives such as
adding a command line argument to override default values.  This
approach really *does* make life complicated, not only because
every program must anticipate the command line argument, but also
because the argument must somehow get explicitly passed into every
exec instead of sliding silently along in the environment.

> in the third place it makes the user's life more difficult.  I'm already
> harassed enough by the size of my environment, thank you.

Sorry to hear that.  I hope it gets better.

> Talking about his proposed solution (posted with the article, John writes
> that if you try out his
> >program, you will recognize one problem.  It's slow.  I claim this is
> >a non-problem: look up your values once, and then run nice and fast.
>
> Give me a break, John.  Do you seriously expect me to wait for you to
> run cc and sed every time I want to start up the editor?  I realize
> that your program is a quick hack, but I don't think we can just
> cavalierly write off startup time.  Most BSD users already run with
> TERMCAP in their environment, solely as a kludge to get around the cost

I'm beginning to see why you are harassed by the size of you environment. :-)

> of reading through /etc/termcap.  We need to remember that startup times
> *are* important, and it is very expensive to open and read through even
> a small file.

I think this is a valid point, although the editor I use already opens
.exrc files in the current directory and my home directory, and
snuffles around in /etc/termcap and who knows what else.  Running the
preprocessor probably wouldn't slow it down much more.  I think Geoff
and I have different visions about what commands might use this
run-time lookup mechanism.  If we assume that the main reason for the
mechanism is to allow runtime lookup of critical values that may
reasonably be expected to vary between binary-compatible machines, then
the mechanism should be of no use to the vast majority of existing
commands.  What does echo need to know that is going to change from
machine to machine?  The applications I had in mind were large data
base applications or other special purpose routines that stressed the
limits of machine resources.  As Geoff points out, the mechanism is
not well suited to commands whose running times are very short.

Volume-Number: Volume 4, Number 5