[GRASS-dev] GRASS_BATCH_JOB vs GUI

[Glynn Clements]

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>