[GRASS5] Need testers for tcltkgrass update for 5.7

[Michael Barton]

Thanks Glynn,

This is a big help in updating tcltkgrass for GRASS 5.7.

I'll check this version on my Mac also and look it over. I'll wait to commit
this until I hear back from Moritz (or anyone else who wants to weigh in on
this). I need to understand which commands need which of the spawn, run, and
term procedures and why.

Ideally, it would be nice if there we only needed 2 ways to run a GRASS
command from tcltkgrass: 1) the command runs via a G_gui() autogenerated
dialog and/or output is returned to a tcltk window; and 2) the command runs
in an xterminal (distinct from the GRASS shell terminal) and output is
directed to the same terminal. Currently, there are only a small percentage
of the GRASS commands that fall into category 2. The rest work fine with the
execute procedure. Can the execute procedure be augmented to permit commands
with arguments that normally run via G_gui to be processed? This would leave
only the tiny fraction that still require an xterm to be dealt with.

Michael


On 8/17/04 4:23 PM, "Glynn Clements" <glynn.clements at virgin.net> wrote:

> 
> Michael Barton wrote:
> 
>> Some of the commands Glynn lists below can be run with his new execute
>> procedure, which automates running a command modally. As he says, commands
>> with arguments much be run the old way with "exec $cmd $arg &". This does
>> include d.mon commands. If they are not run modally, you have no further
>> access to the menu for anything.
> 
> I figured out the problem with the d.mon commands. Because stdout
> wasn't redirected, exec tried to read from it until EOF to return that
> data as its result. "d.mon start=..." forks the driver, so exec
> doesn't get EOF until the driver dies (when a pipe is shared by
> multiple processes, the reader won't receive EOF until *all* writers
> have closed the write end). BTW, this shouldn't apply to stop/select,
> only to start.
> 
>> There are several other commands, including a few not listed here, which
>> still need to run in a separate xterm (r.digit, for example). I've also
>> fixed these so that they run properly.
> 
> The attached version no longer directly uses exec for anything.
> Instead, everything goes through one of four functions:
> 
> execute: runs a command with no arguments in the background;
> this function is intended solely for cases which will end up
> in G_gui().
> 
> spawn: runs a command with arguments in the background (so
> stdout/stderr go to tcltkgrass' stdout/stderr, i.e. the
> terminal from which it was started).
> 
> run: runs a command with arguments in the foreground, with
> stdout/stderr explicitly redirected to tcltkgrass'
> stdout/stderr (to prevent cases such as "d.mon start=..." from
> hanging).
> 
> term: runs a command with arguments on its own xterm, in the
> background.
> 
> Ultimately, "run" should probably be split further. Many commands
> probably *shouldn't* have stdout/stderr redirected, but should return
> this information via exec to be displayed by tcltkgrass (e.g. the
> g.version option should display a dialog rather than dumping the data
> on the terminal from which tcltkgrass was run). Obviously, we can't do
> that for "d.mon start=...". Although maybe the ideal solution there is
> to make the drivers behave more like daemons, i.e. close their
> standard descriptors, start a new session (in the setsid() sense) and
> disassociate from the controlling terminal.
> 
> Also, the xterm case isn't trivial to get right. If xterm is setuid
> (as is the case on many systems, including mine), LD_LIBRARY_PATH is
> reset (as a security measure), typically causing shared GRASS
> libraries to become inaccessible. We really need a "grass-run" script
> which will set LD_LIBRARY_PATH back to the proper value before running
> the specified command.
> 
>> Additional changes include removing references to:
>> 
>> scripting, since it doesn't work anymore
> 
> It doesn't work currently; it isn't out of the question to get it
> working in the future.
> 
>> saving configurations, since that doesn't work anymore (save d.m files
>> instead)
>> configuring netscape, also doesn't work
> 
> BTW, I know that this isn't a tcltkgrass issue, but the default
> GRASS_HTML_BROWSER settings need some work. E.g. they typically don't
> do the right thing if you already have the browser open.
> 
>> g3.setregion and g3.setwind don't work because these scripts are not yet
>> g.parser() compliant. Unless there is a reason NOT to do this, I will go
>> ahead and add the headers to make them autogenerate a GRASS 5.7 GUI dialog.
> 
> Sure. In the meantime, I changed these to use execute as well. Right
> now, nothing will work, as they can't won't work without arguments.
> Once they've been g.parser-ised, execute is the right thing to use.
> 
>> Glynn: the new procedure set_menu_font doesn't work for some reason. It
>> looks like it should, but when I call it from the config menu it says
>> main_menu(font) not found or something to that nature. So I reverted to the
>> previous way of doing this and it works again.
> 
> Duh; I forgot to put "global main_menu" in the procedure.
> 
> -- 
> Glynn Clements <glynn.clements at virgin.net>
> 

______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton