[GRASS-dev] GRASS_BATCH_JOB vs GUI

[Glynn Clements]

Joe O. wrote:

> I was the one corresponding with William about this situation.  What I was
> after was what is provided in Linux.  On Linux systems, I run grass scripts
> embedded within bash scripts and have those run off the clock or from the
> command line.  I have no need for a display nor do I want one.  When the
> process is executed from the command line in Linux it dutifully sits in the
> background, redirecting output to a log file with no interruptions to
> whatever else I may be doing in other windows.  When run off the clock, it
> processes properly as well.  
> 
> When I first tried to execute the scripts in OSX both an X term and a
> Terminal app window would pop up stealing focus from whatever I was doing in
> another window.  The looping in the script would fire off grass repeatedly
> and every time grass would keep the window I was working in at the top of
> the heap but the cursor/mouse focus would be taken away by the X term
> window.
> 
> I realize all the possibilities that are capable with grass scripting to use
> a display even when in GRASS_BATCH_MODE.  I understand the X term is needed
> on the Mac since Grass requires it for the tcltk gui.  However, I know I am
> not going to ask for the display in my scripts.  All the processing I will
> do in this background mode is vector and raster manipulations and
> calculations.  So, what I would like, with caveat emptor, is a switch/shell
> env't var to tell the grass execution not to pop up any other windows/terms,
> especially in Mac OSX.  This switch would put the burden on the programmer
> to ensure their code didn't ask for the X capabilities, but that's a
> responsibility I would be willing to take on to get the quiet, non-focus
> stealing behavior I'm after. 
> 
> I tinkered with the grass.sh script in /Apps.../Grass-6.3.app/Contents/MacOS
> to bypass any of the GUI setup (X and Terminal windows) when GRASS_BATCH_JOB
> is non-empty.  That provided the behavior I was after and didn't interfere
> with interactive use, so setting and acting upon a switch to indicate
> background execution will work.

GRASS_BATCH_JOB is a bit of a hack. You would be better off bypassing
Init.sh altogether.

FWIW, I just set up the GRASS environment from my ~/.bash_profile,
with:

	export GISBASE=/opt/grass-6.3.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_PERL=perl
	export GRASS_TCLSH=tclsh
	export GRASS_WISH=wish
	export GRASS_MESSAGE_FORMAT=silent
	export GRASS_TRUECOLOR=TRUE
	
	export PATH="$GISBASE/bin:$GISBASE/scripts:$PATH"
	export LD_LIBRARY_PATH="$GISBASE/lib"
	export GRASS_LD_LIBRARY_PATH="$LD_LIBRARY_PATH"
	
	export GIS_LOCK=$$
	export GRASS_VERSION="6.3.svn"
	
	tmp=/tmp/grass6-"`whoami`"-$GIS_LOCK
	export GISRC="$tmp/gisrc"
	mkdir "$tmp"
	cp ~/.grassrc6 "$GISRC"

AFAICT, this sets all of the environment variables which Init.sh would
set, even the ones which aren't really necessary (e.g. GRASS_PERL
isn't actually used by any GRASS modules or script; it's only used to
generate the manpages at compile time).

The above would need some minor changes for any given system, e.g. 
setting GISBASE appropriately, using DYLD_LIBRARY_PATH instead of
LD_LIBRARY_PATH on MacOSX, etc).

-- 
Glynn Clements <glynn at gclements.plus.com>