[GRASS5] Environment variable listings...

[Eric G. Miller]

On Fri, Aug 10, 2001 at 09:41:23PM +0100, Glynn Clements wrote:
[snip]
> > These are GRASS variables (GISRC).  That's what g.gisenv manipulates.
> > Normal environment variables are available with "env" command.  The
> > proposal would only have those GRASS variables that are settable (and
> > meaningful) in GISRC (~/.grassrc5).  "g.gisenv" manipulates that file
> > directly with the "set=" argument.
> 
> >From src/display/devices/CELL/Graph_Set.c:
> 
>     if (NULL != (p = getenv ("GRASS_WIDTH")))
> ...
>     if (NULL != (p = getenv ("GRASS_HEIGHT")))

Well, that looks like a bug to me.  I don't know why it wouldn't be
using the G__getenv() routine.  IMHO, *all* GRASS specific environment
variables belong in ~/.grassrc5.  There's no reason user's should have
to pollute their normal environment with variables that are meaningless
outside the GRASS context.

> In this context, GRASS_WIDTH and GRASS_HEIGHT are environment
> variables. Whether these variables appear in $GISRC or what values
> they have there is irrelevant to the CELL driver. All that matters is
> whether they are defined in the environment, and with what values.
> 
> The potential for confusion arises because $GISBASE/etc/Init.sh
> executes "eval `g.gisenv`" under some circumstances (if GRASS_GUI is
> "text", or if it falls back to "text"), which will cause the settings
> in $GISRC to be reflected into the environment.

I still don't see the problem (other than what I stated above).  If the
variable doesn't exist in ~/.grassrc5, "eval `g.gisenv`" won't change
that fact.  The only change I was proposing, was an ability to get a
listing of "possible" environment variables with a little bit of
explanation.  I can't help it that there are code segments which don't
use the GRASS environment variable interface (they should unless it's a
generic well-defined environment variable like $EDITOR).

> However, if the contents of $GISRC and/or the environment are
> subsequently modified so, that the two differ, the version which is
> used depends upon whether the program uses getenv() or G__getenv().

Well, then code using getenv() should change.  This potential *already*
exists.  User's can screw up their location settings as well.  It
doesn't make any sense to have some GRASS specific "environment"
variable specified in ~/.grass.bashrc or ~/.bashrc (or whatever) and
have some others in ~/.grassrc5 and accessed via the libgis API.

I can leave out "environment" variables that aren't accessed via the
libgis API (I wasn't aware that the CELL driver didn't use it).  But I
thought it might be generally useful just to be able to type 
"g.gisenv -l" and get a listing of all the possible "environment"
variables that effect GRASS modules *and* what they mean, what can be
specified, and an example.  If user's can't even find them, then why
have most of 'em?

I guess what we need here is a little consistency.  Either ~/.grassrc5
contains all the settable environment variables that are GRASS specific,
or it shouldn't contain any.  Right now, there's apparently a mixture.

-- 
Eric G. Miller <egm2 at jps.net>