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

[Glynn Clements]

Cedric Shock wrote:

> 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).

The default is to use a pipe, but you can only do so at one end (i.e.
Tcl can read from the command's output, or write to its input, but not
both).

One issue here is that if the command starts a long-running subprocess
(e.g. (re)starting a driver), Tcl won't get EOF from the pipe until
all of the subprocesses have terminated (i.e. no process has a copy of
the descriptor for the remote end of the pipe).

In practice, this means that the command won't terminate until all of
its descendents have terminated. For a foreground command (with no "&"
at the end of the command), the exec call won't return until this
point.

A concrete example of this causing a problem is the d.resize script,
which stops the driver then restarts it with new settings for
GRASS_WIDTH and GRASS_HEIGHT. A Tcl command of the form
"exec d.resize" won't return until the restarted driver terminates.

The reason that command output was redirected was to prevent this
particular situation.

> 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.

Ick. Just live with it until we drop Tcl/Tk in favour of C/C++.

-- 
Glynn Clements <glynn at gclements.plus.com>