[GRASS-dev] another not quiet GRASS command

[Michael Barton]

The problem in this and other cases is that the warning is sent to stderr
when the command operates and exits properly. Error messages are sent to
stderr when the command does not operate properly and/or exits with an
error. There is no easy way (maybe no way in many cases) for a script to
tell the difference.

The result is that an "error" is generated both when the command operates
correctly AND incorrectly. The choice is to display an error message every
time the command runs (ranging from annoying to incapacitating) OR to send
them off to devnull limbo where a user will rarely if ever see a REAL error
message.

While admitedly useful for command line use, an informational message (i.e.,
not a value returned) that is sent by a module when it operates correctly is
completely pointless in a scripting context. When the message is sent to the
output channel that is also used to inform users about a real error, it is a
problem too. Why can't quiet mean quiet since it is an option? Or can there
be a 'super quiet' that really means quiet?

For scripting purposes, the ideal behavior of a module would be to 1) return
a value in an easily parsable form (e.g., key=val\nkey=val\n...) when asked
to do so, 2) return a clear and easily understandable error message that
could help a user/developer when an error occurs; and 3) completely silently
go about its business in all other circumstances.

Michael

On 9/3/07 3:58 AM, "Hamish" <hamish_nospam at yahoo.com> wrote:

> 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

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton