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

[Roger Bivand]

On Tue, 11 Jul 2000, Justin Hickey wrote:

> 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().

Please note the (few) changes I made recently in env.c. They are related
to the ongoing discussion of the library API to libgis.a functions needed
by interfaces to other programs that link against libgis.a - the key thing
is never to expose an unprotected exit(); - always call
G_fatal_error(); first, so that any user-provided error handler is called
first, stopping say env.c functions clobbering the program linked to
libgis.a. env.c had a couple of bad exits, I hope I found the worst ones.

> 
> 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.

Otherwise good ideas!

Roger

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.


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