[GRASS5] Changes to src/libes/gis/env.c

[Justin Hickey]

Hello all

In rewriting the initialization code, I have decided to rewrite the
src/libes/gis/env.c file. The major problem with how GRASS handles environment
variables is that if you try to set an environment variable in the GRASS shell
and then try to use it in a program under the impression that the variable will
be inherited, it won't work. There are other problems with this code but this
is the most important one I think.

Currently, whenever a program calls G_getenv() or G__getenv() only the
variables defined in the .grassrc file are searched. All other environment
variables are ignored (except GISBASE). Thus, any required variables must be
set in .grassrc

Another problem with using environment variables in GRASS is that if a program
sets an environment variable, it is only active for the duration of the
program. If the programmer wants to use the variable in another program, then
it must be stored in a file and read in again. Thus the extensive use of
.grassrc in env.c

I propose to change env.c as follows. Since every program calls gisinit()
(please correct me if I'm wrong here) then we can put inside gisinit() a call
to read the grassrc file (like initEnv()). This will bring the grass
environment variables into the program's scope. Programmers will be able to use
G_getenv() to get any environment variable and G_getenv() will access the
environment (using the C function getenv()), not the grassrc file. In fact,
programmers should never need to access the grassrc file since it will be read
in with gisinit().

For setting environment variables, we can provide 2 functions; G_setenv() and
G_set_perm_env() (set permanent environment variable). The G_setenv() will set
an environment variable for use with the current program (using the C function
putenv()) and it will not be available after the program terminates. The
G_set_perm_env() will not only set an environment variable but it will add it
(or modify an existing one) to the grassrc file so that other programs can use
it.

Does this sound like a reasonable way to handle environment variables?

Any comments are greatly appreciated.

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'