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