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

[Glynn Clements]

Michael Barton wrote:

> >>> If you use Popen objects for command spawning, you can pass a
> >>> completely separate environment via the constructor's "env" parameter,
> >>> e.g.:
> >>> 
> >>> newenv = os.environ.copy()
> >>> newenv.update({"GRASS_RENDER_IMMEDIATE" : "TRUE"})
> >>> subprocess.Popen(..., env=newenv)
> >>> 
> >>> Personally, I would suggest doing that rather than modifying wxgui's
> >>> own environment (os.environ)
> >>> 
> >>> That allows you to set environment variables for a child process
> >>> without having to set them back afterwards. It also makes it
> >>> straightforward to pass different environments to different types of
> >>> child process (e.g. one for display commands, another for
> >>> "computation" commands).
> >> 
> >> This sounds like good advice, though I'm not quite sure where to insert
> >> this. Possibly in the command processor method in gui_utils.py. The other
> >> thing it how to set it back cleanly after the command is run.
> > 
> > The point is that you don't need to set anything back. You aren't
> > modifying os.environ itself, but modifying a copy and using the copy
> > as the child's environment.
> 
> OK. So if there is need for a different environment for a child process, it
> can be set in Popen and then you don't have to worry about it.

Yes.

> Is this behavior why you don't seem to need a close statement
> either?

If you're running the command asynchronously, there probably should be
a close() call. AFAIK, Python will do this automatically if and when
the Popen object is garbage-collected, but you can't be sure when that
will happen, so it's best to call close() explicitly once you're
finished with it.

If you're using a method which reads until EOF and returns the output
as a string, then that will probably perform the close() itself.

-- 
Glynn Clements <glynn at gclements.plus.com>