[GRASS-dev] Python script test

[Glynn Clements]

Michael Barton wrote:

> I haven't tried this without wxPython, but I thought it was needed for  
> the parser code. I'll test it with GRASS 6.4

g.parser calls G_parser(); if the module has at least one required
option but you don't provide any (or if you use --ui), G_parser() will
call G_gui(), which uses either Tcl/Tk or wxPython depending upon the
setting of GRASS_GUI (if it's set to wxpython, you get the wxPython
dialogs, otherwise you get the Tcl/Tk dialogs).

If you have GRASS_GUI=wxpython, it's safe to assume that you have
wxPython installed. If you have GRASS_GUI=tcltk (or, for that matter,
GRASS_GUI=text), you'll get the Tcl/Tk GUI. The fact that the script
which calls g.parser is written in Python doesn't affect it.

> I also wondered about using g.tempfile. The only reason to use it that  
> I can think of is that the temp file ends up in a GRASS mapset rather  
> than the global gmp directory.

I'm not sure if that's good or bad.

The use of <mapset>/.tmp by G_tempfile() is for a very specific
reason.

New cell/fcell are created in that directory and rename()d into place
when the map is closed. But rename() requires that the source and
destination are on the same partition (rename() just adds and removes
directory entries; it doesn't "move" the file's contents).

/tmp and /home are often separate partitions, so trying to create
temporary files in /tmp or $TMPDIR and rename() them into the mapset
directory will quite possibly fail.

The easiest way to ensure that the file is created on the same
partition as the mapset's cell/fcell directory is to create the
temporary files within the mapset directory (if you decide to mount a
separate partition at <mapset>/.tmp, you lose).

But, unless you're playing filesystem games with rename() (or link()),
there isn't actually any need for temporary files to go into the
mapset directory. They could just as easily go into e.g. the
/tmp/grass-<user>-<pid> directory. That may be more efficient, e.g. if
/tmp is a hard disk but GISDBASE is on an NFS share.

Ultimately, it doesn't particularly matter. In any case, the grass.py
module provides a tempfile() function which (currently) uses
g.tempfile, although it could be changed to use e.g. os.tempnam() if
that was preferred.

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