[GRASS-dev] GRASS_BATCH_JOB vs GUI

[Joe O.]

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.

Joe


Glynn Clements wrote:
> 
> 
> William Kyngesburye wrote:
> 
>> I was discussing with someone running GRASS in batch mode, and it's  
>> not clear what is possible with respect to X11, display windows, TclTk  
>> or Python.
>> 
>> I see that in init.sh, a batch script is forced to run in text mode.   
> 
> As well as setting GRASS_GUI, the -text, -tcltk etc options also
> determine how the database/location/mapset settings are obtained. 
> -text uses the curses interface (set_data), -tcltk uses Tcl/Tk
> (gis_set.tcl) etc.
> 
> Back when I used to actually start GRASS sessions via the grass63
> (etc) script, I invariably passed the full path to the mapset
> directory as an argument to avoid the interactive startup altogether
> (my preferred "terminal" is XEmacs' shell-mode, which doesn't support
> curses).
> 
> Nowadays, I just set all the relevant variables from my bash startup
> scripts, so I never explicitly start GRASS sessions (my bash startup
> scripts are sourced from ~/.xsession, so I can use M-! in XEmacs to
> run GRASS commands).
> 
> Personally, I would support skipping the database/location/mapset
> dialog altogether if ~/.grassrc6 already exists and contains valid
> data. You would only be prompted for this information the first time
> you used GRASS. Thereafter, you would get a session using the stored
> settings; you can use g.mapset (or the GUI) if you want to change
> them.
> 
>> Still, a module run without options (intentionally or not) would try  
>> to bring up a TclTk window and require user interaction, thus  
>> potentially disrupting the flow of the script.
> 
> The GUI form should[*] only be displayed if a module is run without
> options but has at least one required option. If the module was called
> from a script, getting a dialog would normally indicate a bug in the
> script.
> 
> [*] However, the parser doesn't actually enforce this. It's normally
> done by the the module skipping the G_parser() call altogether if
> argc==1, i.e.:
> 
> 	if (argc > 1 && G_parser(argc, argv))
> 	    exit(1);
> 
> That's potentially problematic, e.g. if an option has ->multiple=YES
> and a default ->answer setting, it won't get parsed into the ->answers
> array if G_parser() isn't called. But that hasn't been an issue so
> far.
> 
>> Certainly running either the TclTk or Python GUIs in a batch script is  
>> not desirable, but maybe there are possibilities I don't see?
>> Display windows may be useful in a batch script - or not?
> 
> There's no inherent reason why a script shouldn't be interactive. But
> most of the time, you would be better off prompting the user for all
> necessary options at the outset.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/GRASS_BATCH_JOB-vs-GUI-tp16508266p16519926.html
Sent from the Grass - Dev mailing list archive at Nabble.com.