[GRASS5] update: html/env_vars.html
glynn.clements at virgin.net
Mon Sep 22 20:25:36 EDT 2003
Markus Neteler wrote:
> trying to reduce confusion (hopefully I didn't increase it),
> I have updated
> The list is split now into a list of env vars and GRASS vars
> So I hope that I got this right, otherwise please fix directly in CVS.
How did you try to determine which is which? Because a brief glance
indicates that the method wasn't correct. E.g.
1. GRASS_GUI is listed as an environment variable, but is actually a
GRASS variable. Or, rather, it's meant to be a GRASS variable,
although it appears that setting it in the environment will override
any setting in $GISRC.
2. GISBASE and GISRC are listed as GRASS variables, but are actually
environment variables. GISRC absolutely has to be an environment
variable; given that it identifies the file which contains the values
of the GRASS variables, it cannot itself be a GRASS variable.
There are a few others that are definitely in the wrong category (but
for most of them, I wouldn't know which category was correct without
The most reliable way to check is to search the GRASS source tree
(with find/fgrep) for occurrences of the string "getenv". If the
variable name is passed to getenv(), it's an environment variable; if
it's passed to G_getenv() or G__getenv() it's a GRASS variable (except
for GISBASE, which is trapped by G__getenv()).
That leaves scripts. If a script uses e.g. `g.gisenv FOO`, then FOO is
a GRASS variable. If it just uses $FOO, and doesn't use g.gisenv, then
it's an environment variable. If it uses `eval g.gisenv`, shell
variables will obtain their value from $GISRC if it includes a setting
for that variable, and from the environment otherwise. A similar
principle applies to Tcl/Tk scripts, only the syntax is different.
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev