[GRASS5] update: html/env_vars.html

[Glynn Clements]

Markus Neteler wrote:

> trying to reduce confusion (hopefully I didn't increase it),
> I have updated 
>  html/env_vars.html
> 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
actually looking).

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>