[GRASS-dev] GRASS_BATCH_JOB and GISRCRC

Hamish hamish_b at yahoo.com
Sat Aug 30 21:02:01 EDT 2008


Glynn:
> Actually, I really think that any "advanced" use (and I think that
> includes running batch jobs on a cluster) should just bypass Init.sh
> altogether and set the environment variables itself.

FWIW "grass64 -c" and GRASS_BATCH_JOB work nicely, the overhead is pretty
small. I am fine with people bypassing init.sh if they like to, but
personally I don't see it as something to spend much time worrying about.

If we had full parser support available for init.sh it might be less wierd
to add "batch=/path/to/script.sh" on the command line instead of asking
the user to set a GRASS_BATCH_JOB env variable and ensure the executable
bit is set on that file.

 
> Contrary to what might be assumed from the insane complexity of
> Init.sh, manually configuring the GRASS environment can be done with
> as little as:
> 
> 	export GISBASE=/opt/grass-7.0.svn
> 	export GRASS_GNUPLOT='gnuplot -persist'
> 	export GRASS_WIDTH=640
> 	export GRASS_HEIGHT=480
> 	export GRASS_HTML_BROWSER=firefox
> 	export GRASS_PAGER=cat
> 	export GRASS_WISH=wish
> 	export GRASS_PYTHON=python
> 	export GRASS_MESSAGE_FORMAT=silent
> 	export GRASS_TRUECOLOR=TRUE
> 	export GRASS_TRANSPARENT=TRUE
> 	export GRASS_PNG_AUTO_WRITE=TRUE
> 	
> 	export PATH="$GISBASE/bin:$GISBASE/scripts:$PATH"
> 	export LD_LIBRARY_PATH="$GISBASE/lib"
> 	export GRASS_LD_LIBRARY_PATH="$LD_LIBRARY_PATH"
> 	export PYTHONPATH="$GISBASE/etc/python:$PYTHONPATH"
> 	
> 	export GIS_LOCK=$$
> 	export GRASS_VERSION="7.0.svn"
> 	
> 	tmp=/tmp/grass6-"`whoami`"-$GIS_LOCK
> 	export GISRC="$tmp/gisrc"
> 	mkdir "$tmp"
> 	cp ~/.grassrc6 "$GISRC"
> 
> [That is in a script sourced from my ~/.bash_profile; the only time
> Init.sh ever gets run here is if I'm testing changes to Init.sh.]

don't forget to run $GISBASE/etc/clean_temp every now and then to clear
out left over files from processes that die or are terminated before they
get to their final cleanup stage. Considerable cruft can accumulate
during testing & debugging of modules.


Hamish



      



More information about the grass-dev mailing list