[mod.std.unix] limits ltd.

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/22/85)

Date: Fri, 22 Nov 85 08:58:04 cst
From: allegra!jpl (John P. Linderman)

It is possible to combine several of the proposed solutions to
run time lookup of symbolic constants.  For example, one might
do the following to establish the values V1 ... Vn as defined
in file H.h:

1)  Attempt the cc -E lookup in H.h.
2)  If any (or all) values remain undefined, try the table lookup
    in /etc/H.
3)  If the user has specified environment variable H-Vi, use that
    instead of any lookup value.
4)  Return the values.

Shuffle the precedence as you see fit.  You can arrange for /etc/H to
override the values in H.h.  You can ignore what's in the environment.
Perhaps we can agree on what makes the most sense, and then somebody
can crank out a routine for public use.

John P. Linderman  allegra!jpl

Volume-Number: Volume 3, Number 35

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/28/85)

From seismo!gatech!hplabs!sdcrdcf!trwrb!desint!geoff Wed Nov 27 12:50:46 1985
Date: Tue, 26 Nov 85 21:31:36 pst

In article <3625@ut-sally.UUCP> allegra!jpl (John P. Linderman) writes:

>3)  If the user has specified environment variable H-Vi, use that
>    instead of any lookup value.

Have you every typed "show *" on VMS (or whatever the syntax is;  I'm
glad to say I've forgotten)?  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.
In the first place, it increases the cost of forking *and* exec-ing,
in the second place every program has to provide for the variable, and
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.
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff

Volume-Number: Volume 3, Number 43