[GRASS-dev] another not quiet GRASS command

[Hamish]

Michael Barton wrote:
> I'm trying to use g.mapset in the georectifier module for wxgrass. I
> have to switch back and forth between locations and mapsets. For TclTk,
> I used g.gisenv, but thought it would be more convenient to use
> g.mapset here.
> 
> BUT, I've hit the perennial problem of a GRASS command that won't be
> quiet. Regardless of the --q switch, g.mapset insists on dumping a
> warning to stderr.
> 
> g.mapset mapset=PERMANENT location=Spearfish60_test --q
> WARNING: Your shell continues to use the history for the old mapset.
> 
> This causes cmd.Command (wxgrass command processor using
> subprocess.Popen) to report an error when there isn't one.
..
> This might be a useful warning for command line users to get. But for
> scripting, I don¹t want to see ANY warnings or other extraneous output.

Warnings and fatal error messages are not affected by --quiet by design;
they are not optional and need to be passed on to the user.

With any module you can and will get warnings or fatal error messages,
and any GUI wrapper will need to deal with them somehow.

In the above case of georect.tcl, we may ask 1) if switching between
mapsets in the script is really the best solution; 2) if that warning
should be a warning. One might argue that in this case it should use
G_important_message(), not G_warning(), but the warning message reads
quite well IMO. G_important_message("WARNING: ..."); ? Seems kinda
circuitous to me.

> It does nothing except lock up scripts that don't make special
> arrangements to parse such stuff.

Because the calling wrapper is deficient, not the concept of warnings and
error messages. All scripts must make special arrangements to parse
such stuff. This can be aided by a wrapper fn, in the same way as the Tcl
GUI menu has different 'spawn' module launchers. The cure is to fix the
wrapper -- not hide the errors. It is fundamentally wrong to assume that
anything written to stderr automatically means a problem is fatal, and
the GUI code needs to be written with that in mind, even if it is a pain.

> It would make life so much easier for scripting if we could optionally
> turn off ALL returned message except stdout for commands that are
> supposed to return a value and stderr for real errors.

Warnings and fatal errors are "real errors". I guess one problem lies in
the concept of the warning. Is it a warning that the user is sailing in
dangerous waters? or is it a warning that the binary executable module
did something unexpected, but non-fatal? (I'd argue both are needed). Is
it a line item to be logged in GIS_ERROR_LOG or a console? or is it a
standalone pop-up GUI message? (I'd argue that the GUI needs a console).



Note in the C API there is G_suppress_warnings() (in lib/gis/error.c),
/*!
 * \fn int G_suppress_warnings (int flag)
 *
 * \brief Suppress printing a warning message to stderr
 * 
 * \param[in] flag a warning message will be suppressed if non-zero value
is given
 * \return previous flag
*/

Use that at your own peril, it is likely that it will accidentally cause
more trouble than it solves.


... so instead of lots of open and catch statements, I'd suggest that any
call to a module be done using a standard wrapping function, and that
standard wrapping function take care of robust open/close & error
handling, once & correctly. I don't think there's another good way.
Duplicating robust error handling for all external calls is wasted
duplicated effort and as you point out, a pain.


Hamish