[GRASS5] General and gis.m module running (stdout,stderr,exit status) issues

[Cedric Shock]

Hello,

This is a discussion of various issues we are having when running modules and 
programs from inside the guis.

1. stderr from module output creeps into the terminal

This was dealt with before by redirecting stderr to /dev/null. We should 
really be capturing stderr to display as part of the output. Tcl's open 
process commands seem inadequate for this (they can redirect to files and 
even open fileids so there might be a solution using pipes). A helper program 
that merges these streams together and labels each line or chunk with where 
it is from might also be a solution. This might already exist. bash can 
easily merge the streams together (can't tell them apart) and add exit status 
to the end. Running programs via the unix shell would require proper shell 
command line escaping.


2. We can't get exit status from run programs

Tcl's open process commands are inadequate for capturing the exit code of 
programs. A helper program that labels this and adds it to the data in stdout 
may be in order.

3. In gis.m some menu items, like v.digit, run without a GUI and are useless.

The lowdown:
g.parser eats the original standard input
gis.m is run by g.parser
parser.c decides whether or not to show the UI when there are no arguments 
based on whether its standard input is a tty.
When a program is run from inside gis.m parser.c doesn't run the gui because 
stdin isn't a tty.

The solution:
Don't run programs inside gis.m and expect to get a GUI. Either use --tcltk to 
get the code to source, use --ui to force the user interface to come up, or 
run them in a terminal emulator like xterm so that they have a stdin that is 
a tty.

Where it's at:
gmmenu.tcl and gm.tcl (The Gm:xmon proc)

On a similar note opening monitors for programs to use and running the program 
are independent and should be separated somehow. Rewriting Gm:xmon and 
changing the menu entries is probably the best solution.

--Cedric