[GRASS-dev] another not quiet GRASS command

[Glynn Clements]

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.
> 
> (Martin, this seems to be a general issue with cmd.Command. Is there a way
> to work around this for commands that insist on dumping extraneous stuff to
> stderr?)

If cmd.Command considers writing to stderr to constitute an error,
that's a bug in cmd.Command.

That behaviour of Tcl's "exec" is a significant design flaw; it should
not be intentionally replicated by wxGRASS.

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

Many of the warnings which commands generate are quite important, and
shouldn't be hidden for the sake of convenience.

The g.mapset warning is of debatable usefulness (in general; it's
entirely meaningless for the GUI), but there are plenty of others
which are useful.

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

Scripts should not be attempting to parse stderr. The only reasonable
ways to handle stderr output are:

1. Show it to the user.
2. Log it to a file.
3. Discard it, or otherwise ignore it.

> This is a real problem for TclTk, leaving us with the
> necessity of sending all stderr to dev/null so that we only get back error
> messages sent by TclTk.

That's a deficiency of Tcl's process management primitives
("primitive" being the operative term).

> Even for languages like wxPython that can separate
> stderr from stdout, it means that attempts to gracefully trap and display
> errors will incorrectly show an error when something like this happens.

Only if the code mimic's Tcl's bogus concept of what constitutes an
error (i.e. stderr output).

Writing to stderr is *not* an error. Returning a non-zero exit code is
an error.

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

That isn't going to happen.

Apart from the amount of work involved in modifying GRASS, many
library functions can write warnings (and other messages) to stderr,
and don't necessarily provide any mechanism to control whether this
happens, or even to detect that it has happened.

In general terms, stderr is a mechanism for programs to communicate
arbitrary information to the *user*. Programs should not get involved
with reading stderr unless they are doing so in order to act as a
"common carrier" between the program and the user (i.e. to simply pass
the information along).

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