[GRASS5] Environment variable listings...

[Eric G. Miller]

On Sat, Aug 11, 2001 at 11:51:08AM +0100, Glynn Clements wrote:
> 
> Analysing the results of a recursive grep indicate that:
[snip]
> Summary: 21 using G__getenv() and 60 using getenv(), with 2 variables
> occurring in both categories.
> 
> > 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.
> 
> Due to the way in which the environment works, variables which are
> changed by specific commands, (e.g. MONITOR and "d.mon select=...") 
> cannot be implemented as environment variables.

Yes.

> OTOH, some of the above variables have to be environment variables. 
> E.g. the value of TERM has to be taken from the environment, and HOME
> and USER should probably be treated likewise.

Yes.

> In other cases, it's largely irrelevant, but only because GRASS is
> currently tied to the "session" model, and doesn't permit a user to
> run multiple GRASS sessions simultaneously. If this were to change, in
> most cases there would be an advantage to using environment variables,
> as they can be set on a per-process basis.

I think many on this list will agree we don't really like the current
session management system.  Besides this bit about the environment,
the other annoyances include:

  *  Only allowed to run 1 session at a time
  *  Uses "global" mapset lock rather than more appropriate fcntl() file
     locking (as needed).
  *  Inability to change GISDBASE/LOCATION/MAPSET on the fly.
  *  Doesn't play well with multiuser shared data scenario.

I'll not commit the g.gisenv change, since obviously the listing would
be less useful than I originally thought.

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