Agustin Lobo <alobo@ija.csic.es> writes:
I do not see the problem. I used to write quite a number of scripts
(csh) including some simulations of landscape change. The only thing
you must do is to start grass before runing the script. If the
script takes a long time, you can even use nohup and logout. What
you cannot do is to start grass again with different setings while
the script is runing.
This is getting a touch confusing, primarily because of all this talk about
"starting Grass". My take on the issue is this - any shell which makes Grass
calls needs these environment vars defined:
1. GISBASE (path to Grass executables)
2. GISRC (path to a file containing further definitions).
The $GISRC file in turn must define:
3. GISDBASE (path to Grass data)
4. LOCATION_NAME
5. MAPSET
So, in principle, two concurrent shells may employ different $GISRC files and,
hence, different settings. Problems arise, however, if concurrent shells attempt
to work with different regions in the same MAPSET, or if monitor access occurs
concurrently. I don't particularly like the fact that some settings are obliged
to be defined originally within files. In general, Grass makes too much use of
both definition and temporary files; an enhancement which future developers
developers ought to consider.