GRASS and Shell: Difference between revisions
(→See also: swig) |
(templates and updates) |
||
Line 10: | Line 10: | ||
# path to GRASS binaries and libraries: | # path to GRASS binaries and libraries: | ||
export GISBASE=/usr/local/ | export GISBASE=/usr/local/grass64 | ||
export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts | export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts | ||
Line 48: | Line 48: | ||
=== Example === | === Example === | ||
* GRASS shell script job to generate a [http://grass. | * GRASS shell script job to generate a [http://grass.osgeo.org/spearfish/php_grass_earthquakes.php Recent Earthquakes Map] | ||
: ({{website|spearfish/grass_earthquakes.sh}} shell script) | |||
=== Parallel GRASS jobs === | === Parallel GRASS jobs === | ||
Line 62: | Line 63: | ||
chmod u+x $HOME/my_grassjob.sh | chmod u+x $HOME/my_grassjob.sh | ||
export GRASS_BATCH_JOB=$HOME/my_grassjob.sh | export GRASS_BATCH_JOB=$HOME/my_grassjob.sh | ||
grass64 ~/grassdata/spearfish60/neteler/ | |||
The | The grass64 command starts GRASS, executes the contents of the job file and leaves GRASS. Since the normal startup/closure is used, all tmp files are properly removed. | ||
Note: The $HOME variable (or the ~ shortcut) cannot be used in the batch job since the variables are not available here. | Note: The $HOME variable (or the ~ shortcut) cannot be used in the batch job since the variables are not available here. | ||
Line 74: | Line 75: | ||
Along with the "nohup" command you can login to your machine, launch the job and leave the machine again. | Along with the "nohup" command you can login to your machine, launch the job and leave the machine again. | ||
The process will continue after you logged off when you start it with nohup: | The process will continue after you logged off when you start it with nohup: | ||
nohup | nohup grass64 ~/grassdata/spearfish60/neteler/ & | ||
=== Receive a notification when finished === | === Receive a notification when finished === | ||
Maybe put email notification at the end of 'my_grassjob.sh' using the "mail" or the "mutt" program, for example like this: | Maybe put email notification at the end of 'my_grassjob.sh' using the "mail" or the "mutt" program, for example like this: | ||
Line 90: | Line 92: | ||
=== See also === | === See also === | ||
* | * Other GRASS environment {{cmd|variables}} | ||
* [[GRASS_and_Python#Python-SWIG-GRASS_interface|SWIG bindings]] (Python/Perl/etc) | * [[GRASS_and_Python#Python-SWIG-GRASS_interface|SWIG bindings]] (Python/Perl/etc) | ||
[[Category:FAQ]] | [[Category:FAQ]] | ||
[[Category:Linking to other languages]] | [[Category:Linking to other languages]] |
Revision as of 07:14, 11 September 2008
It is fairly easy to write a GRASS job as Shell script which launches GRASS, does the operation and cleans up the temporary files.
Setting the variables
You have to set a couple of variables to enable GRASS command to run (see 'GRASS Batch jobs' below for easier solution!).
See this post to the mailing list. Proabably need to update this wiki page with that information.
# Example in bash shell syntax: # path to GRASS binaries and libraries: export GISBASE=/usr/local/grass64 export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GISBASE/lib # use process ID (PID) as lock file number: export GIS_LOCK=$$ # settings for graphical output to PNG file (optional) export GRASS_PNGFILE=/tmp/grass6output.png export GRASS_TRUECOLOR=TRUE export GRASS_WIDTH=900 export GRASS_PNG_COMPRESSION=1
The following variable defines where the GRASS settings file is stored. This can be anywhere on the system. You could also generate the '.grassrc6' on the fly in your script, even with different name. Just indicate it correctly:
# path to GRASS settings file export GISRC=$HOME/.grassrc6
Now you can test:
# this should print the GRASS version used: g.version # other calculations go here ...
You should cleanup internal tmp files like this:
# run GRASS' cleanup routine $GISBASE/etc/clean_temp # remove session tmp directory: rm -rf /tmp/grass6-$USER-$GIS_LOCK
If this works, you can launch other GRASS commands. The approach works within Shell scripts and also in the command line terminal.
Example
- GRASS shell script job to generate a Recent Earthquakes Map
- ({{{2}}} shell script)
Parallel GRASS jobs
See Parallel GRASS jobs for openMosix, PBS etc.
GRASS Batch jobs
There is (now) an alternative method to easily run jobs in GRASS from a collection of commands in a shell script file. Just define the environmental variable GRASS_BATCH_JOB with the shell script file containing GRASS (or whatever) commands, preferably with full patch. Then launch GRASS and it will be executed. Best is to launch GRASS in -text mode and to provide GISDBASE/location/mapset as parameters. The job scripts needs executable file permissions (chmod).
Example:
chmod u+x $HOME/my_grassjob.sh export GRASS_BATCH_JOB=$HOME/my_grassjob.sh grass64 ~/grassdata/spearfish60/neteler/
The grass64 command starts GRASS, executes the contents of the job file and leaves GRASS. Since the normal startup/closure is used, all tmp files are properly removed.
Note: The $HOME variable (or the ~ shortcut) cannot be used in the batch job since the variables are not available here.
To deactivate the batch job mode, run (bash example):
unset GRASS_BATCH_JOB
Along with the "nohup" command you can login to your machine, launch the job and leave the machine again. The process will continue after you logged off when you start it with nohup:
nohup grass64 ~/grassdata/spearfish60/neteler/ &
Receive a notification when finished
Maybe put email notification at the end of 'my_grassjob.sh' using the "mail" or the "mutt" program, for example like this:
echo "Finished at `date`" > /tmp/done.txt && \ EDITOR=touch mutt -s "Job done" \ me@mydomain.org < /tmp/done.txt && rm -f /tmp/done.txt
or like this:
mail -s "GRASS job $0 finished" me@mydomain.org <<EOF GRASS GIS has finished the batch job $0 EOF
See also
- Other GRASS environment variables
- SWIG bindings (Python/Perl/etc)