[GRASS-dev] Shell scripts
Glynn Clements
glynn at gclements.plus.com
Sun Dec 6 03:02:27 EST 2009
Huidae Cho wrote:
> What the new python scripts do is to append d.* command lines to
> GRASS_PYCMDFILE. Then, the GUI picks up the file and renders new
> images. Your suggestion should work fine and looks very useful. One
> concern is that not all d.* commands render on the GUI (e.g., d.font,
> d.fontlist). However, this can be taken care of in the GUI, I think.
d.font is pointless in 7.0; it sets the font and encoding (which only
persists for the duration of the d.font command) then terminates. ISTR
that it was retained for the benefit of code which uses "d.font -l"
(which should migrate to using d.fontlist instead).
There wouldn't be any point in running either d.font or d.fontlist
when GRASS_PYCMDFILE is in effect, although both will actually
generate a blank image in $GRASS_PNGFILE (anything which calls
D_close_driver() will do so).
While we're on this subject:
It would be more convenient for command-line use if many of the
environment variables used by the display architecture were $GISRC
variables, as they could then be modified by commands. E.g. you could
have a d.font script which uses g.gisenv to set the GRASS_FONT and
GRASS_ENCODING variables. Similarly for d.frame.
However, it would probably be less convenient for the GUI, as it would
need to write out a new $GISRC file for each d.* command.
One solution would be to check for an environment variable, and fall
back to using a $GISRC variable if no environment variable is found.
However, if a variable somehow gets set in the environment, the
corresponding $GISRC variables would stop working, which may be
confusing for the user.
Another solution would be to check for a $GISRC variable, and fall
back to using an environment variable if no $GISRC variable is found.
The main problem here is that it would force the GUI to maintain a
separate $GISRC (although that may already be necessary; how does the
GUI cope if the user runs g.mapset from the command-line?).
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list