[GRASS-dev] GRASS_BATCH_JOB vs GUI

Being resent as this didn’t make it to the list last night. It answers some questions posed, but bottom line, WK’s latest grass.sh - sent directly to me - for OSX provides for my needs. At this time, at least.

Joe

Begin forwarded message:

From: Joe Ostrowski <jtostrowski@comcast.net>
Date: April 5, 2008 11:33:03 PM EDT
To: Hamish <hamish_b@yahoo.com>
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] GRASS_BATCH_JOB vs GUI

To answer your questions…

This is William Kyngesburye’s 6.3.0RC6 for Mac OSX (I’m on 10.4.11) binary installation.

I did modify the .xinitrc so the xterm doesn’t fire off. X11 still does but only once with a revised grass.sh script sent by WK.

In previous grass.sh incarnations provided by WK (I’ve been corresponding with him privately), the GUI didn’t pop up, just the X term and the Terminal app. But just once. No new terms appeared but the focus was given to X every time grass.sh was called from the batch script. In the most recent grass.sh provided by Mr. Kyngesburye, neither of those terminals initiate. Only X11 does, with no xterm. Focus is momentarily taken by X but immediately returned to the top-o-heap window. This only happens once if X is not previously activated.

Problem was not overlapping grass sessions. They were all sequential.

Off-the-clock for me means “cron”, coming from the Linux world. I haven’t dabbled with that yet for OSX, but I think it’s called launchd.

Shell is bash and 10.4 is the first version on this box.

Doing the batch background processing in Linux works fine. It was only on OSX using the WK dist that wasn’t working how I thought it should.

Soooo…

With either my hack based on the GRASS_BATCH_JOB detection keeping X and Terminal at bay or the latest WK version, I’ve got what I need. I don’t believe any other changes are necessary.

Thanks for all the help.

On Apr 5, 2008, at 10:52 PM, Hamish wrote:

Joe O. wrote:

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 first thing I do after installing X11 on Mac OSX is to stop it from
launching a xterm upon X11 startup.

go to a terminal
$ sudo su

cd /etc/X11/xinit

chmod u+w xinitrc

then edit the xinitrc file and #comment out the line at the end which
calls xterm

that stops some of the mess, but GRASS in text mode should never even
call X11, or pop up a new xterm, something else might be doing that.
(binary packager’s startup script?)

FWIW, ISTR that OSX 10.5 launches X11 on process-demand, whereas in
earlier versions you have to launch in manually.

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.

check your ~/.grassrc6 file has “GRASS_GUI: text”. If not, start grass
from the terminal prompt with “grass63 -text” once, then text mode should
be set as the default. (but I think GRASS_BATCH_JOB should be overriding
whatever is there anyway)

to confirm: the gui is not popping up, just extra terminal windows?

Can you add something to your scripts that launch grass to test for an
existing session?

if [ -z “$GISBASE” ] ; then
grass63 /path/to/mapset # to run batch job
else
echo “ERROR: already in a grass session”

shrug, run it anyway

. /path/to/batchjob.sh
fi

is your shell csh or bash? (“echo $SHELL”) If the machine was upgraded
from older versions of OSX, enduring user accounts may still be using
csh.

I tinkered with the grass.sh script

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.

can you islotate the problematic part of the script?

is this a 6.3.0RC or 6.3svn version of GRASS?
self compiled or one of the binary packages? who’s binary package?

by starting scripts “by the clock”, do you mean using OSX’s replacement
for cron jobs? (I forget what they called that)

Glynn:

GRASS_BATCH_JOB is a bit of a hack.

perhaps that is true, but it should work. And if it doesn’t work it
should be fixed.

would a command line option for batch job be better? init.sh could be
written to act in a similar way to GRASS’s G_parser():

grass63 mapset=/path/to/mapset batch=/path/to/batchjob.sh
?

Hamish


You rock. That’s why Blockbuster’s offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com