Hi,
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.
Markus
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 varsSo 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@virgin.net>
On Tue, Sep 23, 2003 at 01:25:36AM +0100, Glynn Clements wrote:
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.
So we are approximating a correct file (the former version wasn't better
in my opinion).
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.
moved.
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.
moved.
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.
So any time someone comes across a bug in this file, he/she may feel
free to fix it. It's in CVS and writable:
html/env_vars.html
Markus