[GRASS-dev] Re: not quite there on fonts

Michael Barton michael.barton at asu.edu
Fri May 11 17:40:15 EDT 2007

On 5/11/07 1:23 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

>> So you're saying if you start a Tcl application (e.g. gis.m) from a Unix
>> shell, and then set an environment variable within the Tcl application,
>> that the shell kind of inherits it backwards and commands run from there
>> will be affected by the changed environment?
> I suppose that's what he was thinking, but that's incorrect.

That's not what I meant, but the rest of this is helpful anyway.

> The environment is part of a process' address space. Every process has
> its own environment. The environment is duplicated along with the rest
> of the address space by fork(), while execve() takes the environment
> as an argument. The other exec* functions are all wrappers around
> execve(); those without the "e" suffix simply pass the existing
> environment.
> IOW, a child process will normally inherit its environment from its
> parent; thereafter, a process can modify its own environment, but not
> the environment of another process.
>> I didn't think of that - I
>> suppose it would be better if Tcl allowed you to specify environment
>> variables that applied only to it and commands spawned from it.
>> But I suppose anyway you can work around it in this case by setting
>> GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it
>> afterwards.
> There's no need. gis.m could leave GRASS_RENDER_IMMEDIATE set to TRUE
> at all times, and only unset it when spawning a child process which is
> going to use an X monitor.

OK. I've changed the TclTk GUI to set GRASS_RENDER_IMMEDIATE to TRUE when it
starts, and have taken the setting/unsetting of this variable out of the
display routine. The font selection works again.

Given what you say above, can I set all of these for the GUI session and not
worry about their impact on how grass functions from the command line during
that session?

    set env(GRASS_BACKGROUNDCOLOR) "ffffff"

> With Python, the situation is better, as the Popen constructor allows
> you to specify an explicit environment for each process. Tcl lacks
> this, so you have to modify your own environment and let the child
> inherit it.

Can we just set the environment at the beginning of the wxPython GUI session
(i.e., in the init for the original gis manager frame in wxgui.py)? Or do we
need to include a Popen somehow when the GUI is launched?


Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

More information about the grass-dev mailing list