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 <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
