Using GRASS commands form unix prompt

[Conn Copas]

Agustin Lobo <alobo at 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.