[GRASS5] Environment variable listings...
Eric G. Miller
egm2 at jps.net
Fri Aug 10 21:27:22 EDT 2001
On Fri, Aug 10, 2001 at 09:41:23PM +0100, Glynn Clements wrote:
> > 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>
More information about the grass-dev