[GRASS5] General and gis.m module running (stdout,stderr,exit status) issues
cedricgrass at shockfamily.net
Mon Apr 3 16:07:34 EDT 2006
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.
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.
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
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.
More information about the grass-dev