[GRASS-dev] another not quiet GRASS command
michael.barton at asu.edu
Mon Sep 3 15:52:21 EDT 2007
So what is *supposed* to happen in a scripting environment is...
1) non-zero exit code returned
2) show whatever is in stderr to the user
1) 0 exit code returned
2) do not report with whatever is in stderr (not because it is unimportant,
but because it is not an error)
If so, then there may be a bug somewhere in cmd.Comand since it is showing
non-meaningful error messages sometimes when the command operates fine.
An aside: g.mapset treats as an error (It says "ERROR", so I assume that it
generates a non-zero exit code) a situation where the location and mapset
are the current location and mapset. IMHO, this should not be an error. I
guess it could be a "warning", but the module is operating correctly in that
it is 'changing' to the location and mapset specified; these just happen to
be the current one.
On 9/3/07 12:36 PM, "Glynn Clements" <glynn at gclements.plus.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
>> 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
> 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
>> 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.
>> 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).
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
More information about the grass-dev